Throughout both the module and this course, we've been executing commands synchronously, which is where our code starts the command and waits for it to finish before reading its output. For many cases, running a command synchronously is the right approach. However, there are some situations where we want to be able to start a command asynchronously, so that our code is able to perform other tasks whilst that command is running. There are many different reasons why our application may want to do this. For instance, it might not need the command to actually finish, or in some cases the command won't ever finish, but the application still needs to process.

For example, let's take a look at the ping command, which if I go ahead and run inside of a terminal, you can see works as follows, where it sends packets to whichever address we pass in as an argument, in this case google.com. Here you can see it's sending up a packet every one second, and will do so for as long as the computer is running, or until I tell the command to cancel, which I can do by pressing Ctrl+C, of which it then produces some nice statistics at the end, letting us know how many packets it transmitted, how many it received back, and the time it took in total. 17,000 milliseconds, so 17 seconds.

However, if we go ahead and execute the ping command inside of our own code, passing in google.com, then if I go ahead and run this code using the gorun command, you can see we don't get any output. Not only that, but if I go ahead and cancel the application using Ctrl+C, you can see that we only get the words signal interrupt, and we don't receive any of the output from the ping command.

For the meantime, don't worry too much about what signal interrupt is. We'll take a look at it a little bit more in this lesson, and a lot more in the next. Instead, let's figure out what's going on with our ping command, and how we can actually get the output from it. To understand what's happening, let's go ahead and take a look at the documentation. Specifically, if we take a look at the command type, and take a look at the run or even the output methods. If we look at the description for the run command, here you can see it starts the specified command and waits for it to complete. This is also the same for the output command as well, it just calls the run command under the hood.

This behaviour is a bit of an issue when it comes to the ping command, or in fact any long running command, as it won't ever exit, and therefore the call to this function won't return and will never receive the output from it, in either case. Therefore, when it comes to long running commands such as the ping command, we need to find a way to be able to start this command asynchronously. In order to do so, we're going to need to use a different method from the ones that we've been using already when it comes to our command type. So not using either the run, the output, or the combined output methods. Instead, we need to use the start method, which starts the specified command, but does not wait for it to complete.

Therefore, to see how this works, let's go ahead and get rid of the code we already have, and replace it with a call to the start method of our command value. We'll do a quick error check just to be safe as well, which we can do as follows, and we'll just do format.Println here, failed, to start command, and we'll log out the error. With that, the ping command should now be executing asynchronously.

However, when I go and open up a new terminal window and use the go run command to execute our application, you'll see it just exits instantly. This is happening because of the same reason we encountered when we started looking at concurrency, which is because we're not providing a wait point for our code, so it just falls through the main function and thinks it's finished. So just like it was with concurrency, we need to add a point where our application will wait. Fortunately, the actual command object provides a method to do so, which is the wait method, which waits for the command to exit and waits for any copying to standard input or copying from standard output or standard error to complete. Additionally, in order to use this method, the command must have been started with the command.start method, which is the fact in our case. So let's go ahead and use the wait method in order to add a synchronisation point.

However, if I now go and run this code, you'll see that it acts the same way as when we were just using the run method, where the only way to exit this code is to press Ctrl+C, and we still don't get any output other than the signal interrupt. However, whilst this may not seem like it, we are in fact making some progress, as we now have a section of code in between where our application starts on line 11, and where we wait for it, on the command.wait method, which is an area we can actually add some code. For example, we can actually print out the line command started, not yet waiting, and we should see it print to the console when we run the go run command.

Before we take a look at some of the things we can do in this section, let's begin by first obtaining the standard output stream. The simplest way to do so would be to go ahead and just pass in the standard out of our command as follows, setting it to be our own processes standard out. And if I now go ahead and run this code, you can see that we're getting the output of the underlying ping command printed to our application's standard out.

Now, to be completely honest, we could have done the exact same thing when it came to using the run method. For example, if I go ahead and change the code to use the run method and get rid of the command.wait, then if we go run this code again, you can see that we're getting the output from the actual ping command underneath. However, whilst we could still get to the output when it came to using the run method, there are some benefits to using an asynchronous model. For example, let's say we want to be able to stop this command after a certain number of seconds. Well, to do so, let's begin by first adding in a sleep for 5 seconds. time.Second as follows.

Then, in order to stop our actual command, we can go ahead and access the process field of the command type, which gives us access to the underlying os.Process, and we can then use the kill method, which will cause the process to exit immediately. Kill does not wait until the process is actually exited, however. Let's just go ahead and make use of it to see what happens. If we go ahead and run this, 5 seconds we should see the process stop and our application end, which it does, and we didn't need to send an operating system signal in order to kill it. This means we can also do something afterwards, say print line, application ended, or command ended, goodnight, let's say. And if we run this code again, after 5 seconds we should see the application close, and we'll see the logline of command ended, goodnight, be printed to the console.

However, one thing you may have noticed, whilst we're able to kill our process, if we go ahead and run it quickly, and go ahead and compare it to the actual ping command that we were using before, as you can see, when I go ahead and cancel this command using ctrl+c, we receive an additional logline of google.com ping statistics, which gives us some more information about the actual ping command. However, when we're killing the code using the command.process.kill method, we don't receive these statistics. This is because when we press ctrl+c with the ping command, we end up sending up something called a signal interrupt, which the ping command itself is intercepting, and then using to terminate gracefully. We'll talk more about graceful termination in a few lessons from now.

However, for the meantime, it would be nice to be able to get the same behaviour when it comes to our own asynchronous process. To achieve that, rather than using the kill method of the command process, which is quite a destructive action - if you read the documentation, it does not wait until the process has actually exited - this only kills the process itself and not any other processes it may have started, so it's quite a last resort measure. Instead, we want to use the signal method, which will allow us to send an operating system signal to the process - for instance, sending interrupt, which as a caveat is not supported or not implemented on Windows - just FYI.

So to send the signal interrupt to our process, let's go ahead and use the command.process.signal and we'll send the os.interrupt signal to it. Now if we go ahead and run our code again - let's get rid of that window - and we use the go run command. This time, after five seconds, we should see the application quit - but we should see the diagnostics as well, or the statistics as well - which we do.

Therefore, by starting our commands asynchronously using the start method, we're able to perform some other tasks. Of course, we could still achieve this by using the run command and wrapping it inside of a goroutine. However, it's still nice to be able to achieve this without needing to resort to concurrency. Additionally, in some cases, we may want to start a command and then not actually wait for it to terminate - either because we don't care, or because doing so would actually be a bad user experience.

For example, let's say we want our application to open up a web browser whenever a user tries to log in or something similar - which is a very common auth flow when it comes to working with a CLI. To do so, let's go ahead and get rid of all of the code inside of our main function - and we'll get rid of these imports as well - and re-import them back in. Then we can go ahead and create a command with the exec.Command, passing in the name of the command, which is going to be xdg-open in this case. If you're on macOS, you can use the open command, and if you're on Windows, I believe you can use the start command - although don't quote me on that.

Then we can go ahead and pass in the URL that we want to open too. In this case, let's open up dreamsofcode.io, which is where you should be watching this video on. Then we can go ahead and just call the command.Start function - we'll just ignore the errors for the meantime - and let's go ahead and print browser - opens - have fun. Now, if I go ahead and quickly close my browser window and open up a new terminal window and run the command using go run - you can see the browser window is now opened up, and the application has continued without waiting for it.

By opening up the browser asynchronously, the code can then proceed, and not need to worry about the browser being closed before it can exit or continue. To show what I mean, if we use the actual wait method of the command, and go ahead and run the code again, this time you'll notice - well hopefully you'll notice - the application is still running, and is in a suspended state, or waiting for the browser to be cancelled. Which could take a bit of time, say if heading on over to a different web page in general. The application will be waiting pretty much forever. And once I finally close the browser - yes, let's quit - you'll see that the application now exited, although it took 33 seconds.

So another reason to start a command asynchronously is in situations where you don't care about the command exiting, or you don't need to wait for it to actually do so, and you want to continue processing - which is very common when it comes to opening up a browser, or just sometimes forking to other tasks. That covers pretty much the basics when it comes to running commands asynchronously.

However, the last thing I think we should quickly cover is the two other pipes when it comes to the respective standard input and output streams. In the last lesson we took a look at the standard input pipe, which provides an io.WriteCloser that we could write data to, and it would be received by the application. On the other side, on the output and error side of it, we have a pipe for each of those streams as well. For example, the standard out pipe, which provides an io.ReadCloser that we can read from, which is a pipe that is connected to the command standard output, and also the standard error pipe, which is also an io.ReadCloser.

By having access to both of these pipes, we can read data asynchronously as it comes into the application, and we have the same benefits that the pipes will be closed when the application exits. To see how this works, let's go ahead and quickly create a pipe for the standard out. And we'll go ahead and ignore the error again, as usual. Then we can go ahead and call the io.Copy command, writing to our standard out, or our processes standard out, and reading from the standard out pipe of the sub command.

Of course, let's change this back to start, that's my mistake. Now if we go and run this code, you can see that the ping command's output is being copied to our standard out, similar to how it was before. However, you'll notice that it's been more than five seconds, and the command isn't exiting. This is because the io.Copy command is blocking, so we actually would need to run this inside of a goroutine, which is in fact a little less convenient than just assigning our standard output to this. However, we're only using the standard output stream in this case, just as an example of using the os pipe.

As you can see, it then exits. In most cases, if you wanted to copy the standard output stream of the command to your standard out, then it would be a better option to just assign the standard output of the command to the processes standard out as follows. However, the reason for using a pipe is so we can do some more interesting things, such as being able to use a scanner. So scanner is equal to bufio.NewScanner, and then we could say log this out with a prefix. So print line command output and then just do the scanner.Text.

Now if I run this, you can see this time we have a prefix for each line that comes through on the standard output stream of the subcommand, or we could even do something such as counting the number of bytes, or counting the number of lines.

In addition to the standard output pipe, a command also provides another pipe for standard error, which can be accessed using the standard error pipe, which is also an io.ReadCloser and an error, and can be used pretty much in the same way as the standard error pipe, no matter what you need. In this example I'm just copying them over to their respective process counterpart, and if I go ahead and run this code, we should just see it run for five seconds before cancelling.

That covers the basics of how you can execute commands asynchronously when it comes to Go and the exec package. Most of the time you'll probably want to run commands synchronously, however there are some times when running them asynchronously and being able to perform tasks at the same time is pretty useful, or in some cases you don't care too much about waiting for the result, such as in the case of when we opened up a web browser.

In any case, that covers the first half of this module where we look at how we can execute commands. In the next part we're going to be digging into some of the concepts we looked at a little in this video, specifically when it comes to signals, of which we saw the interrupt signal used a few times throughout this module, especially when it came to cancelling the ping command in a graceful way. So in the next lesson we're going to take a deeper look at these operating system signals, and how we can intercept them when it comes to our own application in order to handle what to do when we receive one.