1. Jobs and processes
Job control is a feature provided by many shells (including bash and tcsh ) that let you control multiple running commands, or jobs , at once. Before we can delve much further, we need to talk about processes .
Every time you run a program, you start what is called a process. The command ps displays a list of currently running processes, as shown here:
The PID listed in the first column is the process ID , a unique number given to every running process. The last column, COMMAND , is the name of the running command. Here, we're looking only at the processes which Larry himself is currently running. (There are many other processes running on the system as well--`` ps -aux '' lists them all.) These are bash (Larry's shell), and the ps command itself. As you can see, bash is running concurrently with the ps command. bash executed ps when Larry typed the command. After ps has finished running (after the table of processes is displayed), control is returned to the bash process, which displays the prompt, ready for another command.
A running process is also called a job . The terms process and job are interchangeable. However, a process is usually referred to as a ``job'' when used in conjunction with job control --a feature of the shell that lets you switch between several independent jobs.
In most cases users run only a single job at a time--whatever command they last typed to the shell. However, using job control, you can run several jobs at once, and switch between them as needed.
How might this be useful? Let's say you are editing a text file and want to interrupt your editing and do something else. With job control, you can temporarily suspend the editor, go back to the shell prompt and start to work on something else. When you're done, you can switch back to the editor and be back where you started, as if you didn't leave the editor. There are many other practical uses of job control.
Jobs can either be in the foreground or in the background . There can only be one job in the foreground at a time. The foreground job is the job with which you interact--it receives input from the keyboard and sends output to your screen, unless, of course, you have redirected input or output.. On the other hand, jobs in the background do not receive input from the terminal--in general, they run along quietly without the need for interaction.
Some jobs take a long time to finish and don't do anything interesting while they are running. Compiling programs is one such job, as is compressing a large file. There's no reason why you should sit around being bored while these jobs complete their tasks; just run them in the background. While jobs run in the background, you are free to run other programs.
Jobs may also be suspended . A suspended job is a job that is temporarily stopped. After you suspend a job, you can tell the job to continue in the foreground or the background as needed. Resuming a suspended job does not change the state of the job in any way--the job continues to run where it left off.
Suspending a job is not equal to interrupting a job. When you interrupt a running process (by pressing the interrupt key, which is usually Ctrl-C) , the process is killed, for good. Once the job is killed, there's no hope of resuming it. You'll must run the command again. Also, some programs trap the interrupt, so that pressing Ctrl-C won't immediately kill the job. This is to let the program perform any necessary cleanup operations before exiting. In fact, some programs don't let you kill them with an interrupt at all.
Let's begin with a simple example. The command yes is a seemingly useless command that sends an endless stream of y 's to standard output. (This is actually useful. If you piped the output of yes to another command which asked a series of yes and no questions, the stream of y 's would confirm all of the questions.)
Try it out:
The y 's will continue ad infinitum . You can kill the process by pressing the interrupt key, which is usually Ctrl-C. So that we don't have to put up with the annoying stream of y 's, let's redirect the standard output of yes to /dev/null . As you may remember, /dev/null acts as a ``black hole'' for data. Any data sent to it disappears. This is a very effective method of quieting an otherwise verbose program.
Ah, much better. Nothing is printed, but the shell prompt doesn't come back. This is because yes is still running, and is sending those inane y 's to /dev/null . Again, to kill the job, press the interrupt key.
Let's suppose that you want the yes command to continue to run but wanted to get the shell prompt back so that you can work on other things. You can put yes into the background, allowing it to run, without need for interaction.
One way to put a process in the background is to append an `` & '' character to the end of the command.
As you can see, the shell prompt has returned. But what is this `` [1] 164 ''? And is the yes command really running?
The `` [1] '' represents the job number for the yes process. The shell assigns a job number to every running job. Because yes is the one and only job we're running, it is assigned job number 1 . The `` 164 '' is the process ID, or PID, number given by the system to the job. You can use either number to refer to the job, as you'll see later.
You now have the yes process running in the background, continuously sending a stream of y 's to /dev/null . To check on the status of this process, use the internal shell command jobs .
Sure enough, there it is. You could also use the ps command as demonstrated above to check on the status of the job.
To terminate the job, use the kill command. This command takes either a job number or a process ID number as an argument. This was job number 1, so using the command
kills the job. When identifying the job with the job number, you must prefix the number with a percent (`` % '') character.
Now that you've killed the job, use jobs again to check on it:
The job is in fact dead, and if you use the jobs command again nothing should be printed.
You can also kill the job using the process ID (PID) number, displayed along with the job ID when you start the job. In our example, the process ID is 164, so the command
is equivalent to
You don't need to use the `` % '' when referring to a job by its process ID.
There is another way to put a job into the background. You can start the job normally (in the foreground), stop the job, and then restart it in the background.
First, start the yes process in the foreground, as you did before:
Again, because yes is running in the foreground, you shouldn't get the shell prompt back.
Now, rather than interrupt the job with Ctrl-C, suspend the job. Suspending a job doesn't kill it: it only temporarily stops the job until you restart it. To do this, press the suspend key, which is usually Ctrl-Z.
While the job is suspended, it's simply not running. No CPU time is used for the job. However, you can restart the job, which causes the job to run again as if nothing ever happened. It will continue to run where it left off.
To restart the job in the foreground, use the fg command (for ``foreground'').
The shell displays the name of the command again so you're aware of which job you just put into the foreground. Stop the job again with Ctrl-Z. This time, use the bg command to put the job into the background. This causes the command to run just as if you started the command with `` & '' as in the last section.
And you have your prompt back. Jobs should report that yes is indeed running, and you can kill the job with kill as we did before.
How can you stop the job again? Using Ctrl-Z won't work, because the job is in the background. The answer is to put the job in the foreground with fg , and then stop it. As it turns out, you can use fg on either stopped jobs or jobs in the background.
There is a big difference between a job in the background and a job that is stopped. A stopped job is not running--it's not using any CPU time, and it's not doing any work (the job still occupies system memory, although it may have been swapped out to disk). A job in the background is running and using memory, as well as completing some task while you do other work.
However, a job in the background may try to display text on your terminal, which can be annoying if you're trying to work on something else. For example, if you used the command
without redirecting stdout to /dev/null , a stream of y 's would be displayed on your screen, without any way for you to interrupt it. (You can't use Ctrl-C to interrupt jobs in the background.) In order to stop the endless y 's, use the fg command to bring the job to the foreground, and then use Ctrl-C to kill it.
Another note. The fg and bg commands normally affect the job that was last stopped (indicated by a `` + '' next to the job number when you use the jobs command). If you are running multiple jobs at once, you can put jobs in the foreground or background by giving the job ID as an argument to fg or bg , as in
(to put job number 2 into the foreground), or
(to put job number 3 into the background). You can't use process ID numbers with fg or bg .
Furthermore, using the job number alone, as in
is equivalent to
Just remember that using job control is a feature of the shell. The fg , bg and jobs commands are internal to the shell. If for some reason you use a shell that doesn't support job control, don't expect to find these commands available. In addition, there are some aspects of job control that differ between bash and tcsh . In fact, some shells don't provide job control at all--however, most shells available for Linux do. |
