Job Control (Unix Power Tools, 3rd Edition)

23.1. Job Control in a Nutshell

As has been said many times in this book, Unix is a mutliprocessing system. Unlike some historic systems such as MS-DOS, all flavors of Unix run more than one process at a time. In fact, when Unix boots, the first program executed is called init , which is the parent of all future processes. init immediately creates a new process in which other programs can run, such as getty and the various rc setup scripts. At some point when a user logs into the system, the getty program creates a new shell for that session. Even when the system is in single-user mode, Unix is still capable of running multiple processes. Multiprocessing is prevasive in Unix.

But multiprocessing isn't just for system daemons. It's also there to make your interactive shell session just a little bit more productive. Often, you will need to execute a program that takes a long time to run. For instance, you might be downloading a file with FTP or Lynx. It is possible to have that task put into the background so that you may execute new commands while the previous ones are running to completion. Just as you may have several piles of work on your desk, you often need to set aside one stack to work on another. A process is said to be in the foreground when it is receiving your keyboard input and is writing to your screen. Using the desk analogy, the foreground process is that pile of work currently in front of you. Only one process can be in the foreground at a time. Putting a process in the background is like putting the current stack of work in front of you on the floor. And if your desk is anything like mine, you can soon find your desk surrounded by piles of work. Unlike the real world, Unix is able to continue working on completing processes in the background. The management and manipulation of foreground and background processes is called job control. By understanding job control, you can begin to take better advantage of your Unix system.

One cautionary note on job control: there's no such thing as a free lunch. In other words, while Unix blithely lets you put all the processes you want into the background, they all share the same CPU, RAM, and hard drive resources. If one process dominates one of these resources, the other processes won't get done any faster than they would have had you run them one after the other to completion. So if you've got a process that's CPU-intensive (such as a photomosiac program), there's little point in trying to run more processes on that machine.

From the days of mainframes, when programs were submitted on stacks of cards, comes the term "job control." This chapter is going to go into some depth about using your shell's job control features. For those already familar with the concept, here is the thirty-second version of "Job Control in a Nutshell."

Summary Box

Unless otherwise noted, these commands apply only to the C shell, Korn shell, and bash:

command & (Section 23.3)

Run command in the background. You can continue to execute jobs in the foreground. This is the most common way to put processes in the background.

CTRL-c (Section 24.11)

Kill the current foreground job by sending the INTR signal (Section 24.10).

CTRL-z (Section 23.3, Section 23.6)

Suspend the current foreground job by sending the TSTP signal (Section 24.10).

suspend

Suspend a shell with the suspend command.

stop

Suspend a background job with the stop command or an alias that does the same thing (Section 23.7).

bg %num (Section 23.3)

Let a stopped job (by job number num) continue in the background.

fg %num (Section 23.3)

Put a background job or a stopped job (by job number num) into the foreground.

kill %num (Section 23.3)

Kill an arbitrary background job (by job number num).

kill pid (Section 24.12)

Kill an arbitrary job (by process ID number num).

jobs (Section 23.3)

List background and stopped jobs and their job numbers.

set notify (Section 23.8)

Immediate job-state change notices.

stty tostop (Section 23.9)

Automatically stop background processes if they try writing to the screen.

Some systems, like Linux, extend the kill to kill processes by name. See Section 24.15, which introduces killall.

--ML and JJ

Chapter 23. Job Control

Contents:

23.1. Job Control in a Nutshell

Summary Box