Now that we've looked at how to both get output from our command and how to pass input to it, in this lesson we're going to take a moment to talk about how we can actually configure our command further.

To show this in action, if we take a look at the current code I have on screen, here I'm calling the ls command that we saw before, passing in the -la flag. And when I go to run this command, it successfully will print the contents of my current directory. However, what about if I want to print the contents of another directory, say the directory where all of my counter application code is?

On the command line, I could of course just use the ls command and point it to the actual directory relative to where my current code is, such as .. - counter. And it would work. Or I could also pass in the absolute path, so /home/elliott/projects/counter. This would work as well.

Whilst this is fine when it comes to the ls command, what about if we were running a command where we can't point it to another directory? For example, if I try to run the git status command inside of the exec directory, which isn't a git repository, when I go to run this command, it throws an error. However, if I was inside of my counter directory and ran the same git status command, you can see it produces the actual changes inside of my git repository.

Unfortunately, you can't point the git status command to another directory, as it only looks for a git repository inside of your current working directory or any of its parents. Therefore, when it comes to my own terminal, I have to change into the directory that I want to run the git status command with, using the cd command.

However, when it comes to our code, we don't have the cd command available to us. And if I try to run the git status command, such as follows, you'll see when I run this code, it actually produces an exit status of 128.

So how do we go about solving this so we can run the git status command in other directories other than the one that we're currently running our code in? Well, to do so, we need to make use of another property available inside of the cmd struct. This is the dir property, which specifies the working directory of the command. If the dir is an empty string, or the empty string, then the run command runs this command inside of the calling process's current directory.

Therefore, in our case, because we're not setting a directory value for this cmd property, such as here, then our code is being ran in the same directory that we run our application in. This means if we were inside of our counter, and we could go run on the actual exec package as follows, although we're actually outside of it, so it's not going to work.

You can see it sort of works when I just run the main.go file. However, this is somewhat clunky, and in many cases, we'll want to be able to run our command inside of a directory that we're not specifically in. Therefore, let's go ahead and set the dir property of this command to be the directory that contains the counter code, such as /home/elliott/projects/counter.

Now if we go ahead and run our code using the go run command, this time it should no longer fail, and it should produce the git output from the actual directory we asked it to do so. Pretty cool.

This will also work for other commands as well, such as the ls -la command that we saw earlier, which if we go ahead and run again, which if I now go ahead and run will print out the contents of the /counter directory. Additionally, if we go ahead and use the pwd command as follows, you can see that this prints out the path of the current working directory for the command.

In addition to being able to specify the working directory of the command, we can also specify a number of other properties as well, such as extra files, which isn't supported on Windows, the underlying process, any look path errors, a cancel function, and a wait delay. The one we're going to look at in the rest of this lesson is the env property, which specifies the environment of the process.

We'll take a look at environment variables later on in this course, specifically when it comes to how we can interact with them within our own application. However, for the meantime, let's take a look at how we can actually pass environment variables to any sub-commands. If you're unaware, an environment variable is a variable that's available to your process through its current environment.

You can actually print out all of the environment variables available to your current shell by using the env command, which as you can see, there are a lot. Whenever you run code, the environment that's passed into your application is available in the system as well. For example, if we want to set an environment variable on our own machine, we can do so by using the export command, provided you're using a POSIX base shell.

For example, let's say we want to export API_KEY=secret_key as follows. Now, if I run the echo commands with the API_KEY, it should print out the value of the environment variable that we've set, which it does. This is because this environment variable is now available to the echo command, given that it's set within my current environment.

However, let's say we want to pass in an environment variable to a sub command, but not actually set it within our current environment. Well, fortunately, that's where we can use the env property of the command. In order to show how this works, let's go ahead and run the following commands. First, creating a new shell instance and passing in the -C flag, which causes it to run a command.

Then we're going to pass in the command string we want to run, which in this case is going to be echo and then API_SECRET as follows. As we mentioned before, arguments are typically escaped. However, in this case, we want these to be a single argument because it's what we're passing to the shell command. For example, this then resolves echo API_KEY, let's do TOKEN because we know API_KEY because we know that's been set in our environment.

You can see it would work as follows. Whereas if we separated this, such as echo API_KEY, as you can see, it doesn't work mainly because it calls the two individual arguments separately rather than calling it as a single command. In any case, the reason we're doing this is so that we can have access to the API_SECRET environment variable using the following syntax.

So, let's go ahead and now add the API_SECRET environment variable to this command. To do so, we can go ahead and use the env property, which if we take a look at the documentation for, is a slice of string. The env property specifies the environment of the process, with each entry being in the form of key=value.

Therefore, in order to set this, we could use the following slice of string, setting API_SECRET=my_secret_api_key, for example. Okay, with that, we should now be able to print out our API_SECRET, which if I go ahead and run, you can see it's printed to the console. Whereas before, if we go ahead and comment this line out, you can see it doesn't.

However, there is a bit of an issue with taking this approach. For example, as I mentioned before, we have our API_KEY has been set, which is secret_key. And if we go ahead and change our code to now print out the API_KEY, when I go to run this code, we should see the API_KEY be printed, which it is. This is because by default, the command will inherit the environment from its parent process, which in this case is our go run command.

However, if I go ahead and uncomment this line again, where we're setting the environment variable for the API_SECRET=secret_api_key, you can see that our API_KEY no longer exists. This is because by default, if the env property is nil, the new process uses the current process's environment. And by overwriting it with our new environment, we're suddenly causing all of the inherited environment variables to be lost.

Fortunately, there is a way we can solve this, which is to make use of the environ function from the command itself, which returns a copy of the environment in which the command will be run as it's currently configured. Therefore, we can go ahead and use the append function appending to the current environment, our key value pair, which we can do as follows.

Now, if I go ahead and run this code, you should see the secret_key exists. And if we change this to be API_SECRET, I hope that's not too confusing the two difference between the API_KEY and the API_SECRET. Now, if we go ahead and run this, you can see that the API_SECRET is also available as well.

With that, we've taken a look at how we can further customize the execution of our command, either by changing its current working directory or by adding in environment variables. All of this knowledge that we've learned so far in this module will actually be applying to a later lesson where we'll be building our own application that will be able to compile a Go project for all of the different architectures and operating systems that it supports, and will also require the use of changing the directory and passing in environment variables in order to achieve this.

In the next lesson, however, we're going to take a look at asynchronous processes, so executing commands that may take a long time, that we don't want to wait for to finish before executing other code. In the next lesson, however, we're going to take a look at how we can work with asynchronous processes, and how we can also execute commands that are long running, where we don't want to wait for them to finish, or we want to process other code at the same time.