Job control (Unix): Difference between revisions

Content deleted Content added
Edit for uniformity and accuracy; highlight diff between fg and wait
Overview: use job vs process more consistently
Line 22:
 
==Overview==
In a shell, a user has one foreground job but can run multiple jobs in the background. 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 only possible via a foreground processjob. The user interactively enters a command and the implementation of the command (often a program) controls [[standard streams |input and output]] such that the user cannot access the shell until the command completes or the user interrupts it (i.e. via {{keypress|Control|C}}).
 
However, a user may wish to perform an operation while using the shell for another purpose. An operation that is running but not using the interactive input and output is running in the background. The single operation that is using the interactive input and output is running in the foreground. Job control is the facility to control how operations run as foreground or background. A user can start a processjob in the background, send athe runningforeground processesjob to the background, bring a background processjob to the foreground, and suspend or terminate a processjob.
 
A job maps to a single shell command execution which may result in multiple processes starting and completing. Multi-process operations come about because a process may create child processes, and a single shell command may consist of a [[Pipeline (Unix)|pipeline]] of multiple communicating processes. For example, the following command line selects lines containing the text "title", sorts them alphabetically, and displays the result in a [[terminal pager]]: <code>grep title somefile.txt | sort | less</code>. This creates at least three processes: one for [[grep|{{code |grep}}]], one for {{code |sort}}, and one for [[less (Unix)|{{code |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 getsis suspended.
 
JobsAs are manageddefined by the operating system as a single [[process groupPOSIX]], and thea job is themanaged shell'sby internalthe representationoperating ofsystem suchas a group. This is defined in [[POSIXprocess group]] 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>
 
A job can beis referred toidentified 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 [[shell builtin]]s to refer to the job. A job ID beginbegins 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>
{{blockquote|A set of processes, comprising a shell pipeline, and any processes descended from it, that are all in the same process group.}}
 
Job control and job IDs are typically only used in an interactive use,shell. where they simplify referring to process groups; inIn scripting, PGIDs are used instead, as they are more precise and robust, and indeed job control is disabled by default in a bash scriptsscript.
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 [[shell builtin]]s to refer to the job. A job ID 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.
 
==Implementation==