View source for Job control (Unix)

{{Short description|Control of jobs by a Unix shell}}
In [[Software:Unix|Unix]] and [[Unix-like]] [[Operating system|operating system]]s, '''job control''' refers to control of '''jobs''' by a [[Unix shell|shell]], especially interactively, where a "job" is a shell's representation for a [[Process group|process group]]. Basic job control features are the suspending, resuming, or terminating of all processes in the job/process group; more advanced features can be performed by sending signals to the job. Job control is of particular interest in Unix due to its [[Multiprocessing|multiprocessing]], and should be distinguished from job control generally, which is frequently applied to sequential execution ([[Software:Batch processing|batch processing]]).

==Overview==
When using [[Software:Unix|Unix]] or [[Unix-like]] operating systems via a [[Computer terminal|terminal]] (or [[Terminal emulator|terminal emulator]]), a user will initially only have a single process running, their interactive [[Unix shell|shell]] (it may be login shell or may be not). Most tasks{{efn|Here "task" is a non-technical term for "some activity", while "process" and "job" are technical terms.}} (directory listing, editing files, etc.) can easily be accomplished by letting the program take control of the terminal and returning control to the shell when the program exits – formally, by attaching to [[Standard streams|standard input and standard output]] to the shell, which reads or writes from the terminal, and catching signals sent from the keyboard, like the termination signal resulting from pressing {{keypress|Control|C}}.

However, sometimes the user will wish to carry out a task while using the terminal for another purpose. A task that is running but is not receiving input from the terminal is said to be running "in the background", while the single task that is receiving input from the terminal is "in the foreground". Job control is a facility developed to make this possible, by allowing the user to start processes in the background, send already running processes into the background, bring [[Background process|background process]]es into the foreground, and suspend or terminate processes.

The concept of a ''job'' maps the (shell) concept of a single shell command to the (operating system) concept of the possibly many processes that the command entails. Multi-process tasks come about because processes may create additional child processes, and a single shell command may consist of a [[Pipeline (Unix)|pipeline]] of multiple communicating processes. For example, a command to select lines containing the text "title", sort these alphabetically, and display the result in a pager.

<source lang="shell">
grep title somefile.txt | sort | less
</source>

This creates at least three processes: one for {{mono|[[Software:Grep|grep]]}}, one for {{mono|sort}}, and one for [[Software:Less (Unix)|{{mono|less}}]]. Job control allows the shell to control these related processes as one entity, and when a user issues the appropriate key combination (usually {{keypress|Control|Z}}), the entire group of processes gets suspended.

Jobs are managed by the operating system as a single [[Process group|process group]], and the job is the shell's internal representation of such a group. This is defined in [[POSIX]] as:<ref>IEEE Std 1003.1-2001, [http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_201 Section 3.201, Job]</ref>

{{blockquote|A set of processes, comprising a shell pipeline, and any processes descended from it, that are all in the same process group.}}

A job can be referred to by a [[Handle (computing)|handle]]{{efn|A job ID is an abstract reference by the shell to a resource (a process group) managed externally, by the operating system, hence is a handle.}} called the ''job control job ID'' or simply ''{{visible anchor|job ID}}'', which is used by [[Software:Shell builtin|shell builtin]]s to refer to the job. Job IDs begin with the <code>%</code> character; <code>%n</code> identifies job ''n'', while <code>%%</code> identifies the current job. Other job IDs are specified by [[POSIX]].<ref>IEEE Std 1003.1-2001, [http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_203 Section 3.203, Job Control Job ID]</ref> In informal usage the number may be referred to as the "job number" or "job ID", and Bash documentation refers to the (%-prefixed) job ID as the ''jobspec.''<ref>[https://www.gnu.org/software/bash/manual/html_node/Job-Control-Basics.html#Job-Control-Basics 7.1 Job Control Basics]</ref>

Job control and job IDs are typically only used in interactive use, where they simplify referring to process groups; in scripting PGIDs are used instead, as they are more precise and robust, and indeed job control is disabled by default in bash scripts.

==History==
Job control was first implemented in the [[Software:C shell|C shell]] by Jim Kulp,<ref>
Foreword by [[Biography:Bill Joy|Bill Joy]] in {{cite book
    | first = Gail
    | last = Anderson
    | author2 = Paul Anderson
    | year = 1986
    | title = The UNIX C Shell Field Guide
    | page = xvii
    | publisher = Prentice-Hall
    | isbn = 0-13-937468-X
    | url-access = registration
    | url = https://archive.org/details/unixcshellfieldg00ande
    }}
</ref> then at IIASA in Austria, making use of features of the 4.1BSD kernel.
The [[Software:KornShell|KornShell]], developed at Bell Labs, adopted it and it was later incorporated into the SVR4 version of the [[Software:Bourne shell|Bourne shell]], and exists in most modern Unix shells.

==Commands==
{{Missing information|section|wait|date=April 2021}}
The POSIX standard specifies two commands for resuming suspended jobs in the background and foreground, respectively {{mono|bg}} and {{mono|fg}}. These were modeled after the Korn shell job control commands.<ref>{{man|cu|bg|SUS}}; {{man|cu|fg|SUS}}.</ref>

==Implementation==
Typically, the shell keeps a list of jobs in a '''job table'''. Recall that a job corresponds to a process group, which consists of all the members of a [[Pipeline (Unix)|pipeline]] and their descendants. The <code>jobs</code> command will list the background jobs existing in the job table, along with their job number and job state (stopped or running). When a [[Login session|session]] ends when the user logs out (exits the shell, which terminates the ''session leader'' process), the shell process sends SIGHUP to all jobs, and waits for the process groups to end before terminating itself.

The [[Disown (Unix)|<code>disown</code>]] command can be used to remove jobs from the job table, so that when the session ends the child process groups are not sent SIGHUP, nor does the shell wait for them to terminate. They thus become [[Orphan process|orphan process]]es, and may be terminated by the operating system, though more often this is used so the processes are adopted by [[Software:Init|init]] (the kernel sets their parent process to init) and continue executing as daemons. Alternatives to prevent jobs from being terminated include nohup and using a [[Software:Terminal multiplexer|terminal multiplexer]].

A job running in the foreground can be stopped by typing the suspend character (Ctrl-Z). This sends the "terminal stop"  signal ('''SIGTSTP''') to the process group. By default, SIGTSTP causes processes receiving it to stop, and control is returned to the shell. However, a process can register a signal handler for or ignore SIGTSTP. A process can also be paused with the "stop" signal ('''SIGSTOP'''), which cannot be caught or ignored.

A job running in the foreground can be interrupted by typing the interruption character (Ctrl-C). This sends the "interrupt" signal ('''SIGINT'''), which defaults to terminating the process, though it can be overridden.

A stopped job can be resumed as a background job with the <code>[[Software:Bg (Unix)|bg]]</code> [[Software:Shell builtin|builtin]], or as the foreground job with <code>fg</code>. In either case, the shell redirects I/O appropriately, and sends the '''SIGCONT''' signal to the process, which causes the operating system to resume its execution. In [[Software:Bash (Unix shell)|Bash]], a program can be started as a background job by appending an ampersand (<code>&</code>) to the command line; its output is directed to the terminal (potentially interleaved with other programs' output), but it cannot read from the terminal input.

A background process that attempts to read from or write to its controlling terminal is sent a '''SIGTTIN''' (for input) or '''SIGTTOU''' (for output) signal. These signals stop the process by default, but they may also be handled in other ways. Shells often override the default stop action of SIGTTOU so that background processes deliver their output to the controlling terminal by default.

In Bash-compatible shells, the <code>[[Software:Kill (command)|kill]]</code> builtin (not <code>/bin/kill</code>) can signal jobs by job ID as well as by process group ID – sending a signal to a job sends it to the whole process group, and jobs specified by a job ID should be killed by prefixing <code>%</code>. <code>kill</code> can send any signal to a job; however, if the intent is to rid the system of the processes the signals SIGKILL and SIGTERM (the default) are probably the most applicable.

==See also==
* [[Software:C shell|C shell]]

==Notes==
{{Notelist}}

==References==
{{Reflist}}

==Further reading==
* {{cite book|
url=http://www.informit.com/title/0201702452|
title=The Design and Implementation of the FreeBSD Operating System|
author=[[Biography:Marshall Kirk McKusick|Marshall Kirk McKusick]] and George V. Neville-Neil|
date=2004-08-02|
publisher=Addison Wesley|
chapter-url=http://www.informit.com/articles/article.aspx?p=366888&seqNum=8|
chapter=FreeBSD Process Management: Process Groups and Sessions|
isbn=0-201-70245-2}}

==External links==
* "Job Control", [https://web.archive.org/web/20060523213233/http://cnswww.cns.cwru.edu/%7Echet/bash/bashref.html ''Bash Reference Manual'']

[[Category:Unix]]

{{Sourceattribution|Job control (Unix)}}