A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1254 ====================================================================== Reported By: stephane Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1254 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Stephane Chazelas Organization: User Reference: Section: 2.9.3.1 Asynchronous Lists Page Number: 2370 (in 2018 edition, not 2016) Line Number: the whole 2.9.3.1 section and also 76177 (execution environment), 115763 (wait), 128448 (rationale), 74883 ($!) Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2019-06-08 09:14 UTC Last Modified: 2022-06-06 09:48 UTC ====================================================================== Summary: "asynchronous list" description uses "command" instead of "AND-OR list" ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000760 asynchronous list assignment of stdin s... ======================================================================
---------------------------------------------------------------------- (0005845) geoffclare (manager) - 2022-06-06 09:48 https://austingroupbugs.net/view.php?id=1254#c5845 ---------------------------------------------------------------------- Proposed changes... On page 38 line 1270 section 3.33 Background Job, change:<blockquote>See <i>Background Process Group</i> in [xref to 3.35].</blockquote>to:<blockquote>In the context of the System Interfaces volume of POSIX.1-202x, a background process group (see [xref to 3.35]). In the context of the shell, a job that the shell is not waiting for before it executes further commands or, if interactive, prompts for further commands. A background job can be a job-control background job or a non-job-control background job. A job-control background job is a job that started execution (either in the background or the foreground) while job control was enabled and is currently in the background. A non-job-control background job is an asynchronous AND-OR list that started execution while job control was disabled and was assigned a job number. An implementation need not support non-job-control background jobs; that is, the shell may, but need not, assign job numbers to asynchronous AND-OR lists that start execution while job control is disabled. <small><b>Note:</b> Asynchronous AND-OR lists are defined in detail in [xref to XCU 2.9.3.1].</small> <small><b>Note:</b> See also [xref to 3.182 Foreground Job], [xref to 3.202 Job], [xref to 3.203 Job Control], and [xref to 3.379 Suspended Job].</small></blockquote> On page 38 line 1273 section 3.35, change:<blockquote>Background Process Group (or Background Job)</blockquote>to:<blockquote>Background Process Group</blockquote> On page 38 line 1275 section 3.35, add a new paragraph:<blockquote><small><b>Note:</b> See also [xref to 3.33 Background Job].</small></blockquote> On page 62 line 1849 section 3.182 Foreground Job, change:<blockquote>See <i>Foreground Process Group</i> in [xref to 3.184].</blockquote>to:<blockquote>In the context of the System Interfaces volume of POSIX.1-202x, a foreground process group (see [xref to 3.184]). In the context of the shell, a job that the shell is waiting for before it executes further commands or, if interactive, prompts for further commands. <small><b>Note:</b> See also [xref to 3.33 Background Job], [xref to 3.202 Job], and [xref to 3.379 Suspended Job].</small></blockquote> On page 62 line 1852 section 3.184, change:<blockquote>Foreground Process Group (or Foreground Job)</blockquote>to:<blockquote>Foreground Process Group</blockquote> On page 62 line 1857 section 3.184, add a new paragraph:<blockquote><small><b>Note:</b> See also [xref to 3.182 Foreground Job].</small></blockquote> On page 65 line 1924 section 3.202 Job, change:<blockquote>A set of processes, comprising a shell pipeline, and any processes descended from it, that are all in the same process group. <small><b>Note:</b> See also [xref to XCU 2.9.2 Pipelines].</small></blockquote>to:<blockquote>A background job, a foreground job, or a suspended job. In the context of the shell, jobs are created when a list (see [xref to XCU 2.9.3 Lists]) is executed while job control is enabled, and may be created when an asynchronous AND-OR list is executed while job control is disabled. <small><b>Note:</b> Job control in the shell is defined in detail in [xref to XCU 2.11 Job Control].</small> <small><b>Note:</b> See also [xref to 3.33 Background Job], [xref to 3.182 Foreground Job], and [xref to 3.379 Suspended Job].</small></blockquote> After page 65 line 1931 section 3.203 Job Control, add:<blockquote>The term is also used in connection with system interfaces that can be used by a command interpreter to implement job control (see for example [xref to setpgid()]). <small><b>Note:</b> Job control in the shell is defined in detail in [xref to XCU 2.11 Job Control].</small></blockquote> On page 66 line 1932,1935,1936 section 3.204 Job Control Job ID, change:<blockquote>Job Control Job ID</blockquote>to:<blockquote>Job ID</blockquote> On page 66 line 1933 section 3.204 Job Control Job ID, and page 2881,2883 line 95038,95096 section kill, and page 3717 line 127377 section C.1.7 Built-In Utilities, change:<blockquote>job control job ID</blockquote>to:<blockquote>job ID</blockquote> On page 94 line 2625 section 3.379 Suspended Job, change:<blockquote>A job that has received a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal that caused the process group to stop. A suspended job is a background job, but a background job is not necessarily a suspended job.</blockquote>to:<blockquote>In the context of the System Interfaces volume of POSIX.1-202x, a job that has received a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal that caused the process group to stop. In the context of the shell, a job, other than a non-job-control background job, that became suspended when a process returned a wait status to the shell indicating that the process was stopped by a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal. A suspended job is a job-control background job, but a job-control background job is not necessarily a suspended job. A non-job-control background job is never a suspended job, even if it includes processes that have been stopped by a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal. <small><b>Note:</b> See also [xref to 3.33 Background Job], [xref to 3.202 Job], and [xref to 3.182 Foreground Job].</small></blockquote> On page 2350 line 74877 section 2.5.2 Special Parameters (?), after applying bug 1309 change:<blockquote>Expands to the shortest representation of the decimal exit status of the pipeline (see [xref to 2.9.2]) that most recently completed execution and was not executed in a subshell environment. The value shall be set to 0 during initialization of the shell.</blockquote>to:<blockquote>Expands to the shortest representation of the decimal exit status of the pipeline (see [xref to 2.9.2]) executed from the current shell execution environment (not a subshell environment) that most recently either terminated or, optionally but only if the shell is interactive and job control is enabled, was stopped by a signal. If this pipeline terminated, the status value shall be its exit status; otherwise, the status value shall be the same as the exit status that would have resulted if the pipeline had been terminated by a signal with the same number as the signal that stopped it. The value of the special parameter '?' shall be set to 0 during initialization of the shell.</blockquote> On page 2350 line 74883 section 2.5.2 Special Parameters (!), after applying bug 1052, change:<blockquote>Expands to the shortest representation of the decimal process ID of the most recent background command (see [xref to 2.9.3]) executed from the current shell. (For example, background commands executed from subshells do not affect the value of "$!" in the current shell environment.) For a pipeline, the process ID is that of the last command in the pipeline.</blockquote>to:<blockquote>Expands to the shortest representation of the decimal process ID associated with the most recent asynchronous AND-OR list (see [xref to 2.9.3.1]) executed from the current shell execution environment, or to the decimal process ID of the last command specified in the currently executing pipeline in the job-control background job that most recently resumed execution through the use of <i>bg</i>, whichever is the most recent.</blockquote> On page 2369 line 75644 section 2.9.2 Pipelines, change:<blockquote>If the pipeline is not in the background (see [xref to 2.9.3.1]), the shell shall wait ...</blockquote>to:<blockquote>If the pipeline is not in the background (see [xref to 2.9.3.1] and [xref to 2.11 Job Control]), the shell shall wait ...</blockquote> On page 2370 line 75680 section 2.9.3.1 Asynchronous Lists, change:<blockquote><i>Asynchronous Lists</i> If a command is terminated by the control operator <ampersand> ('&'), the shell shall execute the command asynchronously in a subshell. This means that the shell shall not wait for the command to finish before executing the next command. The format for running a command in the background is:<pre><i>command1</i> & [<i>command2</i> & ... ]</pre>If job control is disabled (see <i>set</i>, <b>-m</b>), the standard input for an asynchronous list, before any explicit redirections are performed, shall be considered to be assigned to a file that has the same properties as <b>/dev/null</b>. This shall not happen if job control is enabled. In all cases, explicit redirection of standard input shall override this activity. When an element of an asynchronous list (the portion of the list ended by an <ampersand>, such as <i>command1</i>, above) is started by the shell, the process ID of the last command in the asynchronous list element shall become known in the current shell execution environment; see [xref to 2.12]. This process ID shall remain known until: <ol> <li>The command terminates and the application waits for the process ID.</li> <li>Another asynchronous list is invoked before "$!" (corresponding to the previous asynchronous list) is expanded in the current execution environment.</li> </ol> The implementation need not retain more than the {CHILD_MAX} most recent entries in its list of known process IDs in the current shell execution environment. <b>Exit Status</b> The exit status of an asynchronous list shall be zero.</blockquote>to:<blockquote><i>Asynchronous AND-OR Lists</i> If an AND-OR list is terminated by the control operator <ampersand> ('&'), the shell shall execute the AND-OR list asynchronously in a subshell environment. This subshell shall execute in the background; that is, the shell shall not wait for the subshell to terminate before executing the next command (if any); if there are no further commands to execute, the shell shall not wait for the subshell to terminate before exiting. If job control is enabled (see <i>set</i>, <b>-m</b>), the AND-OR list shall become a job-control background job and a job number shall be assigned to it. If job control is disabled, the AND-OR list may become a non-job-control background job, in which case a job number shall assigned to it; if no job number is assigned it shall become a background command but not a background job. A job-control background job can be controlled as described in [xref to XCU 2.11 Job Control]. The process ID associated with the asynchronous AND-OR list shall become known in the current shell execution environment; see [xref to 2.12]. This process ID shall remain known until any one of the following occurs (and, unless otherwise specified, may continue to remain known after it occurs). <ul> <li>The process terminates and the application waits for the process ID or the corresponding job ID (see [xref to wait]).</li> <li>If the asynchronous AND-OR list did not become a background job: another asynchronous AND-OR list is invoked before "$!" (corresponding to the previous asynchronous AND-OR list) is expanded in the current shell execution environment.</li> <li>If the asynchronous AND-OR list became a background job: the <i>jobs</i> utility reports the termination status of that job.</li> <li>If the shell is interactive and the asynchronous AND-OR list became a background job: a message indicating completion of the corresponding job is written to standard error. If <i>set</i> <b>-b</b> is enabled, it is unspecified whether the process ID is removed from the list of known process IDs when the message is written or immediately prior to when the shell writes the next prompt for input. </li> </ul> The implementation need not retain more than the {CHILD_MAX} most recent entries in its list of known process IDs in the current shell execution environment. If, and only if, job control is disabled, the standard input for the subshell in which an asynchronous AND-OR list is executed shall initially be assigned to an open file description that behaves as if <b>/dev/null</b> had been opened for reading only. This initial assignment shall be overridden by any explicit redirection of standard input within the AND-OR list. If the shell is interactive and the asynchronous AND-OR list became a background job, the job number and the process ID associated with the job shall be written to standard error using the format:<pre>"[%d] %d\n", <job-number>, <process-id></pre>If the shell is interactive and the asynchronous AND-OR list did not become a background job, the process ID associated with the asynchronous AND-OR list shall be written to standard error in an unspecified format. <b>Exit Status</b> The exit status of an asynchronous AND-OR list shall be zero. The exit status of the subshell in which the AND-OR list is asynchronously executed can be obtained using the <i>wait</i> utility.</blockquote> On page 2369 line 75701 section 2.9.3.2 Sequential Lists, change:<blockquote><i>Sequential Lists</i> Commands that are separated by a <semicolon> (';') shall be executed sequentially. The format for executing commands sequentially shall be:<pre><i>command1</i> [; <i>command2</i>] ...</pre>Each command shall be expanded and executed in the order specified. <b>Exit Status</b> The exit status of a sequential list shall be the exit status of the last command in the list.</blockquote>to:<blockquote><i>Sequential AND-OR Lists</i> AND-OR lists that are separated by a <semicolon> (';') shall be executed sequentially. The format for executing AND-OR lists sequentially shall be:<pre><i>aolist1</i> [; <i>aolist2</i>] ...</pre>Each AND-OR list shall be expanded and executed in the order specified. If job control is enabled, the AND-OR lists shall form all or part of a foreground job that can be controlled as described in [xref to XCU 2.11 Job Control]. <b>Exit Status</b> The exit status of a sequential AND-OR list shall be the exit status of the last pipeline in the AND-OR list that is executed.</blockquote> On page 2381 line 76151 section 2, insert a new subsection: <b>2.11 Job Control</b><blockquote>Job control is defined (see [xref to 3.203 Job Control]) as a facility that allows users selectively to stop (suspend) the execution of processes and continue (resume) their execution at a later point. It is jointly supplied by the terminal I/O driver and a command interpreter. The shell is one such command interpreter and job control in the shell is enabled by [xref to set] <b>-m</b> (which is enabled by default in interactive shells). The remainder of this section describes the job control facility provided by the shell. Requirements relating to background jobs stated in this section only apply to job-control background jobs. If the shell has a controlling terminal and it is the controlling process for the terminal session, it shall initially set the foreground process group ID associated with the terminal to its own process group ID. Otherwise, if it has a controlling terminal, it shall initially perform the following steps if interactive and may perform them if non-interactive: <ol> <li>If its process group is the foreground process group associated with the terminal, the shell shall set its process group ID to its process ID (if they are not already equal) and set the foreground process group ID associated with the terminal to its process group ID.</li> <li>If its process group is not the foreground process group associated with the terminal (which would result from it being started by a job-control shell as a background job), the shell shall either stop itself by sending itself a SIGTTIN signal or, if interactive, attempt to read from standard input (which will generate a SIGTTIN signal if standard input is the controlling terminal). If it is stopped, then when it continues execution (after receiving a SIGCONT signal) it shall repeat these steps.</li> </ul> Subsequently, the shell shall change the foreground process group associated with its controlling terminal when a foreground job is running as noted in the description below. When job control is enabled, the shell shall create one or more jobs when it executes a list (see [xref to 2.9.3 Lists]) that has one of the following forms: <ul> <li>A single asynchronous AND-OR list</li> <li>One or more sequentially executed AND-OR lists followed by at most one asynchronous AND-OR list</li> </ul> For the purposes of job control, a list that includes more than one asynchronous AND-OR list shall be treated as if it were split into multiple separate lists, each ending with an asynchronous AND-OR list. When a job consisting of a single asynchronous AND-OR list is created, it shall form a <i>background job</i> and the associated process ID shall be that of a child process that is made a process group leader, with all other processes (if any) that the shell creates to execute the AND-OR list initially having this process ID as their process group ID. For a list consisting of one or more sequentially executed AND-OR lists followed by at most one asynchronous AND-OR list, the whole list shall form a single <i>foreground job</i> up until the sequentially executed AND-OR lists have all completed execution, at which point the asynchronous AND-OR list (if any) shall form a background job as described above. For each pipeline in a foreground job, if the pipeline is executed while the list is still a foreground job, the set of processes comprising the pipeline, and any processes descended from it, shall all be in the same process group, unless the shell executes some of the commands in the pipeline in the current shell execution environment and others in a subshell environment; in this case the process group ID of the current shell need not change (or cannot change if it is the session leader), and consequently the process group ID that the other processes all share may differ from the process group ID of the current shell (which means that a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal sent to one of those process groups does not cause the whole pipeline to stop). A background job that was created on execution of an asynchronous AND-OR list can be brought into the foreground by means of the <i>fg</i> utility (if supported); in this case the entire job shall become a single foreground job. If a process that the shell subsequently waits for is part of this foreground job and is stopped by a signal, the entire job shall become a suspended job and the behavior shall be as if the process had been stopped while the job was running in the background. When a foreground job is created, or a background job is brought into the foreground by the <i>fg</i> utility, if the shell has a controlling terminal it shall set the foreground process group ID associated with the terminal as follows: <ul> <li>If the job was originally created as a background job, the foreground process group ID shall be set to the process ID of the process that the shell made a process group leader when it executed the asynchronous AND-OR list.</li> <li>If the job was originally created as a foreground job, the foreground process group ID shall be set as follows when each pipeline in the job is executed:<blockquote><ul> <li>If the shell is not itself executing, in the current shell execution environment, all of the commands in the pipeline, the foreground process group ID shall be set to the process group ID that is shared by the other processes executing the pipeline (see above).</li> <li>If all of the commands in the pipeline are being executed by the shell itself in the current shell execution environment, the foreground process group ID shall be set to the process group ID of the shell.</li> </ul></blockquote></li> </ul> When a foreground job terminates, or becomes a suspended job (see below), if the shell has a controlling terminal it shall set the foreground process group ID associated with the terminal to the process group ID of the shell. Each background job (whether suspended or not) shall have associated with it a job number and a process ID that is known in the current shell execution environment. When a background job is brought into the foreground by means of the <i>fg</i> utility, the associated job number shall be removed from the shell's background jobs list and the associated process ID shall be removed from the list of process IDs known in the current shell execution environment. If a process that the shell is waiting for is part of a foreground job that was started as a foreground job and is stopped by a catchable signal (SIGTSTP, SIGTTIN, or SIGTTOU): <ul> <li>If the currently executing AND-OR list within the list comprising the foreground job consists of a single pipeline in which all of the commands are simple commands, the shell shall either create a suspended job consisting of at least that AND-OR list and the remaining (if any) AND-OR lists in the same list, or create a suspended job consisting of just that AND-OR list and discard the remaining (if any) AND-OR lists in the same list.</li> <li>Otherwise, the shell shall create a suspended job consisting of a set of commands, from within the list comprising the foreground job, that is unspecified except that the set shall include at least the pipeline to which the stopped process belongs. Commands in the foreground job that have not already completed and are not included in the suspended job shall be discarded.</li> </ul> <small><b>Note:</b>Although only a pipeline of simple commands is guaranteed to remain intact if started in the foreground and subsequently suspended, it is possible to ensure that a complex AND-OR list will remain intact when suspended by starting it in the background and immediately bringing it into the foreground. For example:<pre>command1 && command2 | { command3 || command4; } & fg</pre></small> If a process that the shell is waiting for is part of a foreground job that was started as a foreground job and is stopped by a SIGSTOP signal, the behavior shall be as described above for a catchable signal unless the shell was executing a built-in utility in the current shell execution environment when the SIGSTOP was delivered, resulting in the shell itself being stopped by the signal, in which case if the shell subsequently receives a SIGCONT signal and has one or more child processes that remain stopped, the shell shall create a suspended job as if only those child processes had been stopped. When a suspended job is created as a result of a foreground job being stopped, it shall be assigned a job number, and an interactive shell shall write, and a non-interactive shell may write, a message to standard error, formatted as described by the <i>jobs</i> utility (without the <b>-l</b> option) for a suspended job. The message may indicate that the commands comprising the job include commands that have already completed; in this case the completed commands shall not be repeated if execution of the job is subsequently continued. If the shell is interactive, it shall save the terminal settings before changing them to the settings it needs to read further commands. When a process associated with a background job is stopped by a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal, the shell shall convert the (non-suspended) background job into a suspended job and an interactive shell shall write a message to standard error, formatted as described by the <i>jobs</i> utility (without the <b>-l</b> option) for a suspended job, at the following time: <ul> <li>If <i>set</i> <b>-b</b> is enabled, the message shall be written either immediately after the job became suspended or immediately prior to writing the next prompt for input.</li> <li>If <i>set</i> <b>-b</b> is disabled, the message shall be written immediately prior to writing the next prompt for input.</li> </ul> Execution of a suspended job can be continued as a foreground job by means of the <i>fg</i> utility (if supported), or as a (non-suspended) background job either by means of the <i>bg</i> utility (if supported) or by sending the stopped processes a SIGCONT signal. The <i>fg</i> and <i>bg</i> utilities shall send a SIGCONT signal to the process group of the process(es) whose stopped wait status caused the shell to suspend the job. If the shell has a controlling terminal, the <i>fg</i> utility shall send the SIGCONT signal after it has set the foreground process group ID associated with the terminal (see above). If the <i>fg</i> utility is used from an interactive shell to bring into the foreground a suspended job that was created from a foreground job, before it sends the SIGCONT signal the <i>fg</i> utility shall restore the terminal settings to the ones that the shell saved when the job was suspended. When a background job completes or is terminated by a signal, an interactive shell shall write a message to standard error, formatted as described by the <i>jobs</i> utility (without the <b>-l</b> option) for a job that completed or was terminated by a signal, respectively, at the following time: <ul> <li>If <i>set</i> <b>-b</b> is enabled, the message shall be written immediately after the job becomes suspended.</li> <li>If <i>set</i> <b>-b</b> is disabled, the message shall be written immediately prior to writing the next prompt for input.</li> </ul> In each case above where an interactive shell writes a message immediately prior to writing the next prompt for input, the same message may also be written by a non-interactive shell, at any of the following times: <ul> <li>After the next time a foreground job terminates or is suspended</li> <li>Before the shell parses further input</li> <li>Before the shell exits</li> </ul></blockquote> and renumber the later subsections. On page 2381 line 76152 section 2.11 Signals and Error Handling, change:<blockquote>asynchronous list</blockquote>to:<blockquote>asynchronous AND-OR list</blockquote> On page 2381 line 76177 section 2.12 Shell Execution Environment, change:<blockquote>Process IDs of the last commands in asynchronous lists known to this shell environment</blockquote>to:<blockquote>Background jobs and their associated process IDs, and process IDs of child processes created to execute asynchronous AND-OR lists while job control is disabled; together these process IDs constitute the process IDs ``known to this shell environment''. If the implementation supports non-job-control background jobs, the list of known process IDs and the list of background jobs may form a single list even though this standard describes them as being updated separately.</blockquote> On page 2382 line 76198 section 2.12 Shell Execution Environment, change:<blockquote>asynchronous lists</blockquote>to:<blockquote>asynchronous AND-OR lists</blockquote> On page 2409 line 77104 section 2.14 set (-b), change:<blockquote>It shall cause the shell to notify the user asynchronously of background job completions. The following message is written to standard error: [...] When the shell notifies the user a job has been completed, it may remove the job's process ID from the list of those known in the current shell execution environment; see [xref to 2.9.3.1 Asynchronous Lists]. Asynchronous notification shall not be enabled by default.</blockquote>to:<blockquote>When job control and <b>-b</b> are both enabled, the shell shall write asynchronous notifications of background job completions (including termination by a signal), and may write asynchronous notifications of background job suspensions. See [xref to 2.11 Job Control] for details. When job control is disabled, the <b>-b</b> option shall have no effect. Asynchronous notification shall not be enabled by default.</blockquote> On page 2410 line 77149 section 2.14 set (-m), change:<blockquote>This option shall be supported if the implementation supports the User Portability Utilities option. All jobs shall be run in their own process groups. Immediately before the shell issues a prompt after completion of the background job, a message reporting the exit status of the background job shall be written to standard error. If a foreground job stops, the shell shall write a message to standard error to that effect, formatted as described by the <i>jobs</i> utility. In addition, if a job changes status other than exiting (for example, if it stops for input or output or is stopped by a SIGSTOP signal), the shell shall write a similar message immediately prior to writing the next prompt. This option is enabled by default for interactive shells.</blockquote>to:<blockquote>This option shall be supported if the implementation supports the User Portability Utilities option. When this option is enabled, the shell shall perform job control actions as described in [xref to 2.11 Job Control]. This option shall be enabled by default for interactive shells.</blockquote> On page 2539 line 82126 section bg, change:<blockquote>If job control is enabled (see the description of <i>set</i> <b>-m</b>), the <i>bg</i> utility shall resume suspended jobs from the current environment (see [xref to 2.12]) by running them as background jobs.</blockquote>to:<blockquote>If job control is enabled (see the description of <i>set</i> <b>-m</b>), the shell is interactive, and the current shell execution environment (see [xref to 2.12]) is not a subshell environment, the <i>bg</i> utility shall resume suspended jobs from the current shell execution environment by running them as background jobs, as described in [xref to 2.11 Job Control]; it may also do so if the shell is non-interactive or the current shell execution environment is a subshell environment.</blockquote> On page 2539 line 82130 section bg, delete:<blockquote>Using <i>bg</i> to place a job into the background shall cause its process ID to become ``known in the current shell execution environment'', as if it had been started as an asynchronous list; see [xref to 2.9.3.1].</blockquote> After page 2541 line 82206 section bg, add a new paragraph:<blockquote>The <i>bg</i> and <i>fg</i> utilities are not symmetric as regards the list of process IDs known in the current shell execution environment. Whereas <i>fg</i> removes a process ID from this list, <i>bg</i> has no need to add one to this list when it resumes execution of a suspended job in the background, because this has already been done by the shell when the suspended background job was created (see [xref to 2.11 Job Control]).</blockquote> On page 2786 line 91465 section fg, change:<blockquote>If job control is enabled (see the description of <i>set</i> <b>-m</b>), the <i>fg</i> utility shall move a background job from the current environment (see [xref to 2.12]) into the foreground.</blockquote>to:<blockquote>If job control is enabled (see the description of <i>set</i> <b>-m</b>), the shell is interactive, and the current shell execution environment (see [xref to 2.12]) is not a subshell environment, the <i>fg</i> utility shall move a background job in the current execution environment into the foreground, as described in [xref to 2.11 Job Control]; it may also do so if the shell is non-interactive or the current shell execution environment is a subshell environment.</blockquote> On page 2787 line 91507 section fg (EXIT STATUS), change:<blockquote>The following exit values shall be returned: 0 Successful completion. >0 An error occurred.</blockquote>to:<blockquote>If the <i>fg</i> utility succeeds, it does not return an exit status. Instead, the shell waits for the job that <i>fg</i> moved into the foreground. If <i>fg</i> does not move a job into the foreground, the following exit values shall be returned: >0 An error occurred.</blockquote> On page 2870 line 94571 section jobs, change:<blockquote>in the current session</blockquote>to:<blockquote>in the current shell execution environment</blockquote> On page 2870 line 94575 section jobs, change:<blockquote>The <i>jobs</i> utility shall display the status of jobs that were started in the current shell environment; see [xref to 2.12]. When <i>jobs</i> reports the termination status of a job, the shell shall remove its process ID from ...</blockquote>to:<blockquote>If the current shell execution environment (see [xref to 2.12]) is not a subshell environment, the <i>jobs</i> utility shall display the status of background jobs that were created in the current shell execution environment; it may also do so if the current shell execution environment is a subshell environment. When <i>jobs</i> reports the termination status of a job, the shell shall remove the job from the background jobs list and the associated process ID from ...</blockquote> On page 2870 line 94583 section jobs (-l), change:<blockquote>This information shall include the job number, current job, process group ID, state, and the command that formed the job.</blockquote>to:<blockquote>See STDOUT for details.</blockquote> On page 2870 line 94586 section jobs (-p), change:<blockquote>Display only the process IDs for the process group leaders of the selected jobs.</blockquote>to:<blockquote>Display only the process IDs for the process group leaders of job-control background jobs and the process IDs associated with non-job-control background jobs (if supported).</blockquote> On page 2870 line 94587 section jobs, change:<blockquote>shall display the status of all stopped jobs, running background jobs and all jobs whose status has changed</blockquote>to:<blockquote>shall display the status of all background jobs, both running and suspended, and all jobs whose status has changed</blockquote> On page 2871 line 94629 section jobs, change:<blockquote>process group</blockquote>to:<blockquote>job</blockquote> On page 2871 line 94652 section jobs, change:<blockquote>If the <b>-l</b> option is specified, a field containing the process group ID shall be inserted before the <<i>state</i>> field. Also, more processes in a process group may be output on separate lines, using only the process ID and <<i>command</i>> fields.</blockquote>to:<blockquote>If the <b>-l</b> option is specified: <ul> <li>For job-control background jobs, a field containing the process group ID shall be inserted before the <<i>state</i>> field. Also, more processes in a process group may be output on separate lines, using only the process ID and <<i>command</i>> fields.</li> <li>For non-job-control background jobs (if supported), a field containing the process ID associated with the job shall be inserted before the <<i>state</i>> field. Also, more processes created to execute the job may be output on separate lines, using only the process ID and <<i>command</i>> fields.</li> </ul></blockquote> On page 2872 line 94668 section jobs, change:<blockquote>the process group of a job</blockquote>to:<blockquote>the process group of a job-control background job</blockquote> On page 2872 line 94687 section jobs, change:<blockquote>The <i>jobs</i> utility is not dependent on the job control option, as are the seemingly related <i>bg</i> and <i>fg</i> utilities because <i>jobs</i> is useful for examining background jobs, regardless of the condition of job control. When the user has invoked a <i>set</i> <b>+m</b> command and job control has been turned off, <i>jobs</i> can still be used to examine the background jobs associated with that current session. Similarly, <i>kill</i> can then be used to kill background jobs with <i>kill</i> %<<i>background job number</i>>.</blockquote>to:<blockquote>The <i>jobs</i> utility is not dependent on job control being enabled, as are the seemingly related <i>bg</i> and <i>fg</i> utilities, because <i>jobs</i> is useful for examining background jobs, regardless of the current state of job control. When job control has been disabled using <i>set</i> <b>+m</b>, <i>jobs</i> can still be used to examine the job-control background jobs and (if supported) non-job-control background jobs that were created in the current shell execution environment. See also the RATIONALE for <i>kill</i>() and <i>wait</i>().</blockquote> On page 2879 line 94945 section kill, change:<blockquote>... process that was terminated by a signal, the <i>signal_name</i> corresponding to the signal that terminated the process shall be written.</blockquote>to:<blockquote>... process that was terminated or stopped by a signal, the <i>signal_name</i> corresponding to the signal that terminated or stopped the process shall be written.</blockquote> On page 2880 line 94987 section kill, change:<blockquote>A job control job ID (see [xref to XBD Section 3.204]) that identifies a background process group to be signaled. The job control job ID notation is applicable only for invocations of <i>kill</i> in the current shell execution environment; see [xref to 2.12].</blockquote>to:<blockquote>A job ID (see [xref to XBD Section 3.204]) that identifies a process group in the case of a job-control background job, or a process ID in the case of a non-job-control background job (if supported), to be signaled. The job ID notation is applicable only for invocations of <i>kill</i> in the current shell execution environment; see [xref to 2.12]. <small><b>Note:</b> The job ID type of <i>pid</i> is only available on systems supporting the User Portability Utilities option or supporting non-job-control background jobs.</small></blockquote> After page 2883 line 95095 section kill, add a new paragraph:<blockquote>The use of job ID notation is not dependent on job control being enabled. When job control has been disabled using <i>set</i> <b>+m</b>, <i>kill</i> can still be used to signal the process group associated with a job-control background job, or the process ID associated with a non-control background job (if supported), using <i>kill</i> %<<i>background job number</i>> See also the RATIONALE for <i>jobs</i>() and <i>wait</i>().</blockquote> On page 3430 line 115763 section wait, change:<blockquote>When an asynchronous list (see [xref to 2.9.3.1) is started by the shell, the process ID of the last command in each element of the asynchronous list shall become known in the current shell execution environment; see [xref to 2.12].</blockquote>to:<blockquote>The <i>wait</i> utility shall wait for one or more child processes whose process IDs are known in the current shell execution environment (see [xref to 2.12]) to terminate.</blockquote> On page 3430 line 115773 section wait, change:<blockquote>The known process IDs are applicable only for invocations of <i>wait</i> in the current shell execution environment.</blockquote>to:<blockquote>Once a process ID that is known in the current shell execution environment (see [xref to 2.12]) has been successfully waited for, it shall be removed from the list of process IDs that are known in the current shell execution environment. If the process ID is associated with a background job, the corresponding job shall also be removed from the list of background jobs.</blockquote> On page 3430 line 115780 section wait, change:<blockquote>The unsigned decimal integer process ID of a command, for which the utility is to wait for the termination.</blockquote>to:<blockquote>The unsigned decimal integer process ID of a child process whose termination the utility is to wait for.</blockquote> On page 3430 line 115782 section wait, change:<blockquote>A job control job ID (see [xref to XBD Section 3.204]) that identifies a background process group to be waited for. The job control job ID notation is applicable only for invocations of <i>wait</i> in the current shell execution environment; see [xref to 2.12]. The exit status of <i>wait</i> shall be determined by the last command in the pipeline. <small><b>Note:</b> The job control job ID type of <i>pid</i> is only available on systems supporting the User Portability Utilities option.</small></blockquote>to:<blockquote>A job ID (see [xref to XBD Section 3.204]) that identifies a process group in the case of a job-control background job, or a process ID in the case of a non-job-control background job (if supported), to be waited for. The job ID notation is applicable only for invocations of <i>wait</i> in the current shell execution environment; see [xref to 2.12]. The exit status of <i>wait</i> shall be determined by the exit status of the last pipeline to be executed. <small><b>Note:</b> The job ID type of <i>pid</i> is only available on systems supporting the User Portability Utilities option or supporting non-job-control background jobs.</small></blockquote> On page 3431 line 115818 section wait, change:<blockquote>If one or more operands were specified, all of them have terminated or were not known by the invoking shell, and the status of the last operand specified is known, then the exit status of wait shall be the exit status information of the command indicated by the last operand specified.</blockquote>to:<blockquote>If one or more operands were specified, all of them have terminated or were not known in the invoking shell execution environment, and the status of the last operand specified is known, then the exit status of wait shall be the status of the last operand specified.</blockquote> On page 3431 line 115828 section wait, change:<blockquote>The command identified by the last <i>pid</i> operand specified is unknown.</blockquote>to:<blockquote>The process ID specified by the last <i>pid</i> operand is not known in the invoking shell execution environment.</blockquote> After page 3431 line 115838 section wait, add a new paragraph:<blockquote>The use of job ID notation is not dependent on job control being enabled. When job control has been disabled using <i>set</i> <b>+m</b>, <i>wait</i> can still be used to wait for the process group associated with a job-control background job, or the process ID associated with a non-control background job (if supported), using <i>wait</i> %<<i>background job number</i>> See also the RATIONALE for <i>jobs</i>() and <i>kill</i>().</blockquote> On page 3431 line 115839-115853 section wait, delete the text that begins with:<blockquote>Historical implementations of interactive shells have discarded ...</blockquote> and ends with:<blockquote>... work without losing status on any of the jobs.</blockquote> On page 3432,3433 line 115857,115858,115859,115863,115896 section wait, change:<blockquote>asynchronous</blockquote>to:<blockquote>asynchronous AND-OR</blockquote> On page 3432 line 115868 section wait, add a new paragraph:<blockquote>Some historical shells returned from <i>wait</i> when a process stops instead of only when it terminates. This standard does not allow <i>wait</i> to return when a process stops for two reasons: <ol> <li>The vast majority, if not all, shell scripts that use <i>wait</i> (without using an extension) expect it not to return until the process terminates.</li> <li>It is not possible to write a portable shell script that can correctly handle <i>wait</i> returning when a process stops, because an exit status indicating a process was stopped by a signal cannot be distinguished from one indicating that the process called <i>exit</i>() with the same value.</li> </ol> The standard developers considered allowing interactive shells to return from <i>wait</i> when a process stops, since the interactive user would see a message which would allow them to tell whether the process stopped or terminated. However, they decided that it would be inadvisable to introduce an inconsistency between interactive and non-interactive shells, particularly as the most likely use of <i>wait</i> in an interactive shell is to try out commands before putting them in a shell script. Implementations can provide an extension that could be used to request that <i>wait</i> returns when a process stops. It is recommended that any such extension uses a different method of returning information about the wait status of the process so that the information can be unambiguous. One suitable method would be an option that takes a variable name as an option-argument. The named variable would be set to a numeric value and the exit status of <i>wait</i> would indicate whether this value is an exit value or a signal number, and whether the signal terminated the process or stopped it. Such an extension would also provide a way for shell scripts to obtain the full exit value (as would be returned by waitid()).</blockquote> On page 3433 line 115904 section wait, change FUTURE DIRECTIONS from:<blockquote>None.</blockquote>to:<blockquote>A future version of this standard may add an option which takes a variable name as an option-argument, allowing <i>wait</i> to return information about the wait status of a process in an unambiguous way.</blockquote> On page 3494 line 118117 section A.3 Definitions (Job Control), change:<blockquote>which causes the foreground job to stop and the shell to begin prompting for new commands. The stopped job can be ...</blockquote>to:<blockquote>which causes the foreground process group to stop, and the shell to convert the corresponding foreground job to a suspended job and begin prompting for new commands. The suspended job can be ...</blockquote> On page 3494 line 118121 section A.3 Definitions (Job Control), change:<blockquote>If a background job attempts to access the login terminal (controlling terminal), it is stopped by the terminal driver and the shell is notified, which, in turn, notifies the user.</blockquote>to:<blockquote>If a background process group attempts to access the login terminal (controlling terminal), it is stopped by the terminal driver and the shell detects this and, in turn, suspends the corresponding background job and notifies the user.</blockquote> On page 3494 line 118124 section A.3 Definitions (Job Control), change:<blockquote>can continue the stopped job in the foreground</blockquote>to:<blockquote>can continue the suspended job in the foreground</blockquote> On page 3494 line 118128 section A.3 Definitions (Job Control), change:<blockquote>The interactive interface described previously can be accomplished using the POSIX.1 job control facilities in the following way.</blockquote>to:<blockquote>The job control features of the POSIX shell (described in [xref to XCU 2.11 Job Control) and of other shells can be implemented using the job control facilities of the System Interfaces volume of POSIX.1-202x in the following way.</blockquote> On page 3494 line 118134 section A.3 Definitions (Job Control), change:<blockquote>The shell places each job in a separate process group via the <i>setpgid</i>() function.</blockquote>to:<blockquote>The shell places the process(es) it creates for each job in a separate process group via the <i>setpgid</i>() function.</blockquote> On page 3495 line 118144 section A.3 Definitions (Job Control), change:<blockquote>all processes in the pipeline (job)</blockquote>to:<blockquote>all processes in the job</blockquote> On page 3495 line 118146 section A.3 Definitions (Job Control), delete:<blockquote>The shell itself is considered to be a job and is the sole process in its own process group.</blockquote> On page 3495 line 118154 section A.3 Definitions (Job Control), change:<blockquote>The shell, in turn, informs the terminal I/O driver via the <i>tcsetpgrp</i>() function. This indicates to the terminal I/O driver the process group ID of the foreground process group (job). When the current foreground job either stops or terminates, the shell places itself in the foreground via <i>tcsetpgrp</i>() before prompting for additional commands. Note that when a job is created the new process group begins as a background process group. It requires an explicit act of the shell via <i>tcsetpgrp</i>() to move a process group (job) into the foreground.</blockquote>to:<blockquote>The shell, in turn, informs the terminal I/O driver via the <i>tcsetpgrp</i>() function. This indicates to the terminal I/O driver the process group ID of the foreground process group. When the current foreground job either stops or terminates, the shell places its own process group in the foreground via <i>tcsetpgrp</i>() before prompting for additional commands. Note that when a job is created the new process group begins as a background process group. It requires an explicit act of the shell via <i>tcsetpgrp</i>() to move a process group into the foreground.</blockquote> On page 3495 line 118167 section A.3 Definitions (Job Control), change:<blockquote>To continue a stopped job, the shell sends the SIGCONT signal to the process group of the job. In addition, if the job is being continued in the foreground, the shell invokes <i>tcsetpgrp</i>() to place the job in the foreground before sending SIGCONT.</blockquote>to:<blockquote>To continue a suspended job, the shell sends a SIGCONT signal to the corresponding process group. In addition, if the job is being continued in the foreground, the shell invokes <i>tcsetpgrp</i>() to place the process group in the foreground before sending SIGCONT.</blockquote> On page 3495 line 118175 section A.3 Definitions (Job Control), change:<blockquote>Note that the terms ``job'' and ``process group'' can be used interchangeably. A login session that is not using the job control facilities can be thought of as a large collection of processes that are all in the same job (process group). Such a login session may have a partial distinction between foreground and background processes; that is, the shell may choose to wait for some processes before continuing to read new commands and may not wait for other processes. However, the terminal I/O driver will consider all these processes to be in the foreground since they are all members of the same process group.</blockquote>to:<blockquote>A login session that is not using the job control facilities can be thought of as a large collection of processes that are all in the same job. Such a login session may have a partial distinction between foreground and background processes; that is, the shell waits for some processes before continuing to read new commands and does not wait for other processes. However, the terminal I/O driver considers all these processes to be in the foreground since they are all members of the same process group.</blockquote> On page 3495 line 118184 section A.3 Definitions (Job Control), change:<blockquote>When a foreground (not background) job stops, the shell must sample and remember the current terminal settings so that it can restore them later when it continues the stopped job in the foreground</blockquote>to:<blockquote>When a foreground (not background) job is suspended, the shell needs to sample and remember the current terminal settings so that it can restore them later when it continues the suspended job in the foreground</blockquote> On page 3495 line 118187 section A.3 Definitions (Job Control), change:<blockquote>Because a shell itself can be spawned from a shell, it must take special action to ensure that subshells interact well with their parent shells. A subshell can be spawned to perform an interactive function (prompting the terminal for commands) or a non-interactive function (reading commands from a file). When operating non-interactively, the job control shell will refrain from performing the job control-specific actions described above.</blockquote>to:<blockquote>Because a shell itself can be spawned from a shell, it must take special action to ensure that child shells interact well with their parent shells. A child shell can be spawned to perform an interactive function (prompting the terminal for commands) or a non-interactive function (reading commands from a file). When operating non-interactively, the job control shell will by default refrain from performing the job control-specific actions described above.</blockquote> On page 3496 line 118196 section A.3 Definitions (Job Control), change:<blockquote>An interactive subshell can be spawned from another job control-cognizant shell in either the foreground or background. (For example, from the C Shell, the user can execute the command, csh &.) Before the subshell activates job control ...</blockquote>to:<blockquote>An interactive child shell can be spawned from another job control-cognizant shell in either the foreground or background. (For example, the user can execute an interactive shell in the background by means of the command "sh &".) Before the child shell activates job control ...</blockquote> On page 3742 line 128447 section C.2.9.3 Lists, change:<blockquote><b>Asynchronous Lists</b> The grammar treats a construct such as:<pre>foo & bar & bam &</pre>as one ``asynchronous list'', but since the status of each element is tracked by the shell, the term ``element of an asynchronous list'' was introduced to identify just one of the foo, bar, or bam portions of the overall list.</blockquote>to:<blockquote><b>Asynchronous AND-OR Lists</b></blockquote> On page 3742 line 128458 section C.2.9.3 Lists, change:<blockquote>asynchronous lists</blockquote>to:<blockquote>asynchronous AND-OR lists</blockquote> On page 3742 line 128466 section C.2.9.3 Lists, change:<blockquote><b>Sequential Lists</b></blockquote>to:<blockquote><b>Sequential AND-OR Lists</b></blockquote> On page 3747 line 128643 section C.2, add a new subsection: <b>C.2.11 Job Control</b><blockquote>See also [xref to Job Control subsection of A.3 Definitions]. Shell implementations differ regarding how much of a foreground job is retained when it is converted to a suspended job. For example, given this foreground job:<pre>sleep 10; echo foo; echo bar &</pre>if this is suspended during execution of the <i>sleep</i>, <i>ksh93</i> retains all of the commands in the suspended job and executes them when <i>fg</i> is used:<pre><b>^Z[1] + Stopped sleep 10; echo foo; echo bar &</b> <b>$</b> jobs <b>[1] + Stopped sleep 10; echo foo; echo bar &</b> <b>$</b> fg <b>sleep 10; echo foo; echo bar foo [1] 30686 bar $</b></pre>However, some other shells create a suspended job containing only the <tt>sleep 10</tt> command. Some historical shells did not handle suspending a foreground AND-OR list well. They would treat the wait status of a process that indicated it had stopped as if it was a non-zero exit status and (if the next operator in the AND-OR list was ||) would execute the remainder of the AND-OR list at that point. This behavior is not allowed by the standard for two reasons: <ol> <li>It does not meet the fundamental requirement of an AND-OR list that the decision on whether to execute each part (except the first) is made based on the exit status of the previous part when it completes.</li> <li>It can lead to data loss. For example, consider a user who often runs this command:<pre>generate_report > report.out || rm report.out</pre>with the intention that the incomplete results from a failed <i>generate_report</i> run are never retained in order that they can't be mistaken for a complete set of results. If one day the user decides to check on the progress of the command by stopping it and examining what has been written so far, they will find that the <b>report.out</b> file has already been removed.</li></ol></blockquote>and renumber the later subsections. Issue History Date Modified Username Field Change ====================================================================== 2019-06-08 09:14 stephane New Issue 2019-06-08 09:14 stephane Name => Stephane Chazelas 2019-06-08 09:14 stephane Section => 2.9.3.1 Asynchronous Lists 2019-06-08 09:14 stephane Page Number => 2370 (in 2018 edition, not 2016) 2019-06-08 09:14 stephane Line Number => the whole 2.9.3.1 section and also 76177 (execution environment), 115763 (wait), 128448 (rationale), 74883 ($!) 2019-06-10 18:34 stephane Note Added: 0004416 2019-07-15 15:38 Don Cragun Relationship added related to 0000760 2022-06-06 09:48 geoffclare Note Added: 0005845 ======================================================================
