## 23.2. Job Control Basics

If you're coming from a Windows or MacOS desktop, Unix job control may seem a little strange at first, but both of those operating systems support a form of job control too. The Windows' taskbar shows the foreground application as a depressed icon. In the classic Mac interface, the current application's icon is present in the upper righthand corner. Such displays aren't possible on the command line (although there are similar metaphores available in modern X11 desktop environments like Gnome and KDE). This article tries to give you some background into, er, background processes.

### 23.2.1. How Job Control Works

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.

### 23.2.2. Using Job Control from Your Shell

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.

Here's the tip of the iceberg:

- 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]

--TOR and JJ

Copyright © 2003 O'Reilly & Associates. All rights reserved.