Running Commands in the Background

Ordinarily, when the shell runs a command, it waits until the command is completed before it resumes its dialog with you. During this time, you cannot communicate with the shell-it does not prompt you for input, and you cannot issue another command. In some cases, you may want to start one command and then run another immediately, without waiting for the first to finish. This is especially true when you run a command that takes a long time to finish-while it’s working, you can be doing something else.

An & symbol at the end of a command line directs the shell to execute the command in the background. When a command is run in the background, the system will continue to process it while the shell prompts you for another command. As an example, formatting a long document using the troff text formatter (discussed on the companion web site) often takes a long time, so you ordinarily run troff in the background:

 $ troff big_file & [1] 1413

The shell acknowledges your background command with a message that contains two numbers. The first number, which is enclosed in brackets, is the job ID of this command. It is a small number that identifies which of your current jobs this is. The section “Job Control” later in this chapter explains how you can use this number with the shell job control features to manage your background jobs. The other number, “1413" in this example, is the process ID. It is a unique number that identifies this process among all of the processes in the system. Process IDs and their use are discussed in Chapter 11.

You can also run a pipeline of several commands in the background. The following command runs the troff formatter on big_file and sends the result to the printer:

 $ troff big_file | lp &

All of the programs in a pipeline run in the background, not just the last command.

Running Windowed Commands

If you are using a graphical environment, such as GNOME or KDE, you will at times find yourself running commands that open in new windows. For example, you can open a new xterm window by typing

 $ xterm

However, your previous shell will then wait for you to close that window, ending the xterm command, before accepting any new input. In general, it’s better to run the command in the background. So, to open a firefox browser window, you would enter

 $ firefox &

This will allow you to switch back and forth between your various windows, using them all simultaneously

Standard 1/0 and Background Jobs

When you run a command in the background, the shell starts it, gives you a job identification message, and then prompts you for another command. It disconnects the standard input of the background command from your keyboard, but it does not automatically disconnect its standard output from your screen. So output from the command, whenever it occurs, shows up on your screen. Having the output of a background command suddenly dumped on your screen while you are entering another command, or using another program, can be very confusing. Thus when you run a command in the background, you also usually redirect its output to a file:

 $ troff big_file > output &

When you run a command in the background, you should also consider whether you want to redirect standard error. You may sometimes want the standard error to appear on your screen so that you find out immediately if the command is successful or not, and why On the other hand, if you do not want error messages to show up on your screen, you should redirect standard error as well as standard output-either to the same file or to a different one.

The find command can be used to search through an entire directory structure for files with a particular name. This is a command that can take a lot of time, and you may want to run it in the background. In addition, find may generate messages through standard error if it encounters directories that you do not have permission to read. The following example uses the find command to search for files whose names end in .backup. It starts the search in the current directory, “.”, puts the filenames that it locates into the file called backupfiles, puts error messages in the file find.err, and runs the command in the background. This is how the command line would look in the Bourne-compatible shells (sh, ksh, and bash):

 $ find . -name "*.backup" -print > backupfiles 2> find.err &

or in the C shells (csh and tcsh):

 $ (find . -name "*.backup" -print > backupfiles) >& find.err &

To discard standard error entirely, redirect it to /deυ/null, which will cause it to vanish. (/deυ/null is a device that does nothing with information sent to it. It is like a black hole into which input vanishes. Sending output to /deυ/null is a handy way to get rid of it.) The command

 $ troff big_file > output 2> /dev/null &

runs the troff command in the background on big_file, sends its output to output, and discards error messages. In csh or tcsh, this would look like

 $ (troff big_file > output) >& /dev/null &

Logging Off with Active Jobs

If you run a command that takes a very long time, you may want to log out before it finishes. Ordinarily, if you log out while a background job is running it will be terminated. However, you can use the nohup (no hang up) command to run a job that will continue running even if you log out. For example,

 $ nohup find / -name "lost_file" -print > lostfound 2>&1 &

in the Bourne-compatible shells, or

 $ nohup find / -name "lost_file" -print >& lostfound &

in the C shells, allow find to continue even after you quit. This command starts looking in the root directory of the file system for any files named lost_file. Any pathnames that are found are put in the file named lostfound, along with any error messages. The whole thing is run in the background, to allow you to enter other commands or log out.

When you use nohup, you should be sure to redirect both standard output and standard error to files, so that when you log back in you can find out what happened. If you do not specify output files, nohup automatically sends command output, including standard error, to the file nohup.out.