You start a job from your terminal, waiting impatiently as it executes. You know you have better ways to spend your time. What's a person to do? Well, Unix's C and K shells provide job control tools to deal with such a dilemma. Withjob control you suspend a program from the foreground (that high priority category in which terminal jobs run for quick response) and, if desired, place it in the background where it executes detached from your terminal. In both cases this frees your terminal for other work while keeping the program running in the computer's memory. You may return the job to foreground at any time. (While it seems like a foregone conclusion that all users have multi-windowing terminals, someday you may find yourself at poor Cascadia State College with a ``dumb'' terminal and then you'll have more respect for these commands.) The requisite commands are:
With job control you can execute any number of jobs at once, although
only one job may be in the foreground. Yet, in a multi-windowing
environment such as X Windows or Sun Windows, each window may
have an active foreground job as well as background ones. Because
background jobs requiring terminal input stop and wait to be placed in
the foreground, it makes sense to place compute-bound jobs in the
background and switch among several active jobs as they progress from
computation to interactive input.
A common use of job control, especially during program development, is switching between editor and compiler. Suspending and continuing an editor is faster than reloading it. This becomes significant as the files get larger, or if you switch a lot, or if your system is being used a lot. Further, this places you back into your file at your previous location.
You may find that you like job control so much that you edit several
files at once, using ctrl-z to suspend one editing session and
fg to continue another. To be this controlling you must
specify which jobs to continue-else fg or bg
applies to just the last job. To find out what the computer knows
about the jobs you have given it, use the jobs command. It
will give you a number to reference your job, its
status,
and the command you entered to execute the job. For example:
% jobs Tell me about stopped jobs. [1] Stopped vi myprog.c A suspended editing. [2] Stopped vi myotherprog.c [3] Stopped cc canonical.c % bg 3 Place job #3, compilation, in background. % jobs Prompt means OK, but I'll check. [1] Stopped vi myprog.c [2] Stopped vi myotherprog.c [3] Running cc canonical.c See #3 run. % fg 2 Resume editing myotherprog.c.
In the next example we suspend a job, run it in background, check
its status, and then work on something else while waiting for Unix to
tell us the background job is finished:
% ls List files in my current directory. % myprog.c test-data A C source code and some data. % cc myprog.c A foreground compilation. ctrl-z Enter stop-command before prompt. Stopped Unix says foreground job stopped. % bg Place last job into background. [1] cc myprog.c Unix talks about your background job. % jobs [1] You ask for the status of job #1. Running cc myprog.c Unix tells what's running. % lpq Tell me about line-printer queue. no entries At most, Unix says nothing's waiting. [1] Done cc myprog.c Without prodding, Unix says it's done. % ls List files in working directory. a.out* myprog.c test-data cc created the a.out.