In a Unix or Unix-like operating system, job control refers to controlling a process group as a job via a shell. Control features include suspend, resume, and terminate, and more advanced features can be performed by sending a signal to a job. Job control allows a user to manage processing in the Unix-based multiprocessing environment, and is distinct from general computing job control.

Job control was first implemented in the C shell by Jim Kulp, then at IIASA in Austria, making use of features of the 4.1BSD kernel. The KornShell, developed at Bell Labs, adopted it and it was later incorporated into the SVR4 version of the Bourne shell, and exists in most modern Unix shells.

A job encompasses all of the processes that start for the handling of a shell command line. A simple command line may start just one process, but a command line may result in multiple processes since a process can create child processes, and a command line can specify a pipeline of multiple commands. For example, the following command line selects lines containing the text "title", sorts them alphabetically, and displays the result in a terminal pager: grep title somefile.txt | sort | less. This creates at least three processes: one for grep, one for sort, and one for less. Job control allows the shell to control these processes as one entity.

A job is identified by a numeric job ID, a.k.a. job number which is classified as a handle since it is an abstract reference to a resource (a process group). An ID value, prefixed with %, can be used with a job control command to specify a job. The special references %% and %+ refer to the default job; the one that would be selected if none specified. Bash documentation refers to a reference (starting with %) as a jobspec (short for job specification).

Job control ID values are typically only used in an interactive shell. In scripting, PGID values are used instead, as they are more precise and robust, and indeed job control is disabled by default in a bash script.

By default, a job runs in the foreground where it uses interactive input and output. The user enters a command line and interacts with the processes but cannot issue another command until the current job terminates. Many operations (i.e. listing files) are relatively quick so the user can wait for a response with little down time and some operations (i.e. editing) require interaction that is only possible via a foreground job. But, if interaction is not required and the operation prevents access to the shell for a long time, the user may want to run it in the background – where the processes cannot access interactive input but the user can perform other foreground operations while the background job runs concurrently. By default background jobs output to the interactive output stream which results in the interleaving of output from the foreground and background jobs although a user may redirect output for a background job to prevent this.

POSIX specifies the user interface to job control – modeled on the Korn shell.. The commands are typically implemented as shell builtins; not separate programs.

The interprocess communication of job control is implemented via signals.