Job control (Unix)

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 , and one for less (Unix)|. Job control allows the shell to control these processes as one entity. ==Job ID==

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 were 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. ==Foreground/background==

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. ==Control==

POSIX specifies the user interface to job control modeled on the Korn shell. The commands are typically implemented as shell builtins, not separate programs. ; Start in background :If a command line ends with , then the job starts in the background. ; Pause foreground job :The foreground job can be paused by pressing . In this state, a job can be resumed in the background via or resumed in the foreground via . ; Command :Command (short for foreground) moves background job to the foreground, either the job specified or the one most recently added to the background if none specified. When the foreground job is paused (via ), then this command resumes that job. ; Command :Command wait pauses the interactive session until the specified background jobs complete or for all background jobs of the active shell if none specified. ; Command :Command (short for background) moves the paused foreground job to the background and resumes it. ; Command :Command reports information about each background job including ID, command line and running status (stopped or running). ==Signals==

The interprocess communication of job control is implemented via signals. Typically, a shell maintains information about background jobs in a job table. When an interactive session ends (i.e. user logs out), the shell sends signal SIGHUP to all jobs, and waits for the process groups to exit before terminating itself. Some shells provide a non-POSIX command disown that removes a job from the job table. The process group becomes an orphan. The shell will not send it SIGHUP, nor wait for it to terminate. This is one technique for enabling a process as a daemon owned directly by the root process init. The POSIX command nohup| provides an alternate way to prevent a job from being terminated by the shell. Suspending the foreground job (via ) sends signal SIGTSTP (terminal stop) to the processes of the group. By default, this signal causes a process to pause so that the shell can resume. However, a process can ignore the signal. A process can also be paused via signal SIGSTOP (stop), which cannot be ignored. When the user presses , the shell sends signal SIGINT (interrupt) to each foreground job process, which defaults to terminating it, though a process can ignore the signal. When a stopped job is resumed (via or ), the shell redirects Input/output and resumes it by sending signal SIGCONT to it. A background process that attempts to read from or write to its controlling terminal is sent signal SIGTTIN (for input) or SIGTTOU (for output). 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, the kill builtin (not /bin/kill) can signal jobs by ID as well as by process group ID. Sending a signal to a job sends it to each process of the group. kill 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.