To get a better feel for how to use job control, a brief look at how Unix handles processes can be helpful. As was mentioned in the opening section, Unix systems normally are running many processes at once. A process is defined as a program that is executing in memory, as opposed to an executable file (i.e., the program) that is sitting on the filesystem. When you log into a Unix system, you are running some shell program (e.g., tcsh or bash). When you ask the shell to run another program, such as vi, a new process starts and takes over the terminal from the shell. That new process is in the foreground by default. When you type commands, it is vi that responds, not the shell. When you exit vi, that process ends and parent process, the shell, returns. When you run vi, the shell itself goes into the background. You've been using background processes all along.

You may have noticed that I slipped in a new concept about processes in the last paragraph. Process are related to each other in hierarchical way by the kernel. When you execute a command from the shell, that new command is a child process of the shell. When a process terminates, the parent process is notified and is given an opportunity to take some action. What happens when you log out? All your shell's child processes are terminated along with the shell process itself, and your system's getty daemon waits for a new user to log in. What happens when getty dies? The ultimate ancestor for all system processes on a Unix system is init. When init dies, the system is halted.

Remember that the shell sits there listening to what you type and calling other programs to do jobs that it doesn't have built-in commands to do.

Normally, when the shell calls another program, it waits for the other program to finish. The ampersand (&) at the end of a command line tells the shell not to wait.

Basically all shells allow background processing. On systems that have job control (Section 23.3), however, most shells will give you a lot of extra capabilities for manipulating background processes.

• If you forget to put a job into the background, you can stop it on the fly with a suspend signal (Section 24.1) by typing CTRL-z. Then use the bg command to put it into the background and restart it:

  % find /usr -name tim -print > mine
  CTRL-z
  Stopped
  % bg
  [1]    find /usr -name tim -print > mine &

• You can bring the current background job ( Section 23.5) into the foreground with the fg command. This is handy when Unix stops the background job that needs input from your keyboard (you can't type to jobs running in the background).

• If you have a lot of background processes running, you can use the jobs command to list them all, then bring a selected job into the foreground by job number. You can also kill jobs by job number rather than by process ID. [Recall that job numbers are per-session numbers that the shell generates, whereas process IDs are generated by the operating system and are visible to all other processes. -- JJ]