Anonymous | Login | 2023-11-29 19:40 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0001254 | [1003.1(2016/18)/Issue7+TC2] Shell and Utilities | Objection | Error | 2019-06-08 09:14 | 2022-09-27 15:29 | ||
Reporter | stephane | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Applied | ||||||
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 | Approved | ||||||
Final Accepted Text | Note: 0005888 | ||||||
Summary | 0001254: "asynchronous list" description uses "command" instead of "AND-OR list" | ||||||
Description |
That's a follow-up on my Note: 0004410 comment on 0000760. 2.9.3 correctly specifies that "an '&' separator or terminator shall cause asynchronous execution of the preceding AND-OR list." In POSIX shells, rc-like shells and csh-like shells, zsh being the only exception that I know, a && b || c & is interpreted as: { a && b || c; } & not a && b || { c & } But 2.9.3.1 then only talks about "commands" started asynchronously, not even pipelines let alone AND-OR lists. The sentence: "When an element of an asynchronous list (the portion of the list ended by an <ampersand>, such as command1, 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 Shell Execution Environment. This process ID shall remain known until:..." doesn't make sense. Without giving a proper definition of "asynchronous list", it suggests that in: false && cmd2 & The pid of cmd2 (what's the pid of a command btw?) should somehow become known (as $! presumably) whenever cmd2 is started (if ever it's started which is unlikely in that example). What should $! be until then? The wait utility description has similar wording, worse in that it suggests $! should be updated for every command run in the list. I suspect at some point "asynchronous list" must have been (confusingly) defined in the grammar as a sequence of 1 more of "and-or-list &" which would explain. There's a clue about that in the rationale at line 128448: << The grammar treats a construct such as: foo & bar & bam & 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. >> So the "component of an asynchronous list" in 2.9.3.1 probably does not refer to the pipeline component of the asynchronously started AND-OR list, but to one AND-OR list component of a "and-or-list1 & and-or-list2 & and-or-list3 &". AFAICT, in the current version of the spec, asynchronous_list is not defined in the grammar (it wasn't in SUSv2 either). "and_or" is. Which process we get in $! is important as we want to know what the effect of killing that process will be and it's important that calling "wait" on that pid should give us the exit status of the AND-OR-list. |
||||||
Desired Action |
- Clearly define what is meant by an asynchronous list. The definition suggested by the rationale (cmd1 && cmd2 & cmd3 || cmd4 & being *one* asynchronous list) but AFAICT absent from the current specification is confusing. I'd rather it be one single "AND-OR list" run asynchronously with & as there's no reason to treat "list1 & list2 & list3 & list4" (with the exclusion of list4) as part of a single construct. If that definition is chosen, the text in 2.9.3.1 the wait utility and the rationale at least would have to be updated. Calling it an "asynchronous *AND-OR* list" might even remove even more confusion . - Update 2.9.3.1, and $!/wait/execution environment description to remove the reference to "command" and replace with "AND-OR list" - Clarify that the pid stored in $! should be the id of a child process that runs a subshell to execute that and_or list, make it clear that that process will exit with the exit status of the and_or list, and that if the and_or list consists of a single pipeline, the last component of the pipe line will be executed by that pid (sleep 1 | sleep 2 & sleep 1; kill "$!" should stop the execution of "sleep 2", same for sleep 2 & sleep 1; kill "$!") |
||||||
Tags | issue8 | ||||||
Attached Files | |||||||
|
![]() |
|||||||||||||||||||
|
![]() |
|
(0004416) stephane (reporter) 2019-06-10 18:34 |
I think that it makes sense to address the other objections I raised in Note: 0004410 and Note: 0004411 of 0000760 in this same bug. the new bug760 wording of: > If job control is disabled (see set, −m), 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 /dev/null. This shall not happen if job > control is enabled. In all cases, explicit redirection of > standard input shall override this activity. seems to assume "my" definition of "asynchronous list" as it doesn't make sense to speak of "the standard input for an asynchronous list" when that asynchronous list can be "cmd1 & cmd2 &". If "redirection of standard input shall override this activity", that would imply in cmd1 < foo & cmd2 & cmd2's stdin would not be redirected to /dev/null. IMO, after "asynchronous list" has been clearly defined as "AND-OR-list followed by &", and maybe renamed to "asynchronous AND-OR list", that whole paragraph should be changed to something like: } If job control is disabled (see set, −m), an implementation may } choose to assign the standard input of an asynchronous AND-OR } list to an open file description that behaves as if /dev/null } had been opened in read-only. } } This shall not happen if job control is enabled. } } Where and if that happens, that shall happen before any explicit } redirection of any command in the asynchronous AND-OR list is } processed. } } A portable application that needs to make sure that is done } would need to make the /dev/null redirection explicitly: } } < /dev/null cmd1 | cmd2 && < /dev/null cmd3 & } } Or } } { cmd1 | cmd2 && cmd3 ; } < /dev/null & } } A portable application that needs to make sure it is not done } would need to duplicate the original stdin outside of the } asynchronous AND-OR list and restore it inside for instance as: } } { <&3 3<&- cmd1 | 3<&- cmd2 && <&3 3<&- cmd3 & } <&3 } } Or: } } { { cmd1 | cmd2 && cmd3 ; } <&3 3<&- & } } } As whether it is done or not in: } } cmd1 | cmd2 && cmd3 & } } Is unspecified. |
(0005845) geoffclare (manager) 2022-06-06 09:48 edited on: 2022-06-06 09:51 |
Proposed changes... On page 38 line 1270 section 3.33 Background Job, change: See Background Process Group in [xref to 3.35].to: In the context of the System Interfaces volume of POSIX.1-202x, a background process group (see [xref to 3.35]). On page 38 line 1273 section 3.35, change: Background Process Group (or Background Job)to: Background Process Group On page 38 line 1275 section 3.35, add a new paragraph: <small>Note: See also [xref to 3.33 Background Job].</small> On page 62 line 1849 section 3.182 Foreground Job, change: See Foreground Process Group in [xref to 3.184].to: In the context of the System Interfaces volume of POSIX.1-202x, a foreground process group (see [xref to 3.184]). On page 62 line 1852 section 3.184, change: Foreground Process Group (or Foreground Job)to: Foreground Process Group On page 62 line 1857 section 3.184, add a new paragraph: <small>Note: See also [xref to 3.182 Foreground Job].</small> On page 65 line 1924 section 3.202 Job, change: A set of processes, comprising a shell pipeline, and any processes descended from it, that are all in the same process group.to: A background job, a foreground job, or a suspended job. After page 65 line 1931 section 3.203 Job Control, add: 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()]). On page 66 line 1932,1935,1936 section 3.204 Job Control Job ID, change: Job Control Job IDto: Job ID 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: job control job IDto: job ID On page 94 line 2625 section 3.379 Suspended Job, change: 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.to: 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. On page 2350 line 74877 section 2.5.2 Special Parameters (?), after applying bug 1309 change: 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.to: 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. On page 2350 line 74883 section 2.5.2 Special Parameters (!), after applying bug 1052, change: 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.to: 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 bg, whichever is the most recent. On page 2369 line 75644 section 2.9.2 Pipelines, change: If the pipeline is not in the background (see [xref to 2.9.3.1]), the shell shall wait ...to: 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 ... On page 2370 line 75680 section 2.9.3.1 Asynchronous Lists, change: Asynchronous Liststo: Asynchronous AND-OR Lists On page 2369 line 75701 section 2.9.3.2 Sequential Lists, change: Sequential Liststo: Sequential AND-OR Lists On page 2381 line 76151 section 2, insert a new subsection: 2.11 Job Control 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] -m (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. and renumber the later subsections. On page 2381 line 76152 section 2.11 Signals and Error Handling, change: asynchronous listto: asynchronous AND-OR list On page 2381 line 76177 section 2.12 Shell Execution Environment, change: Process IDs of the last commands in asynchronous lists known to this shell environmentto: 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. On page 2382 line 76198 section 2.12 Shell Execution Environment, change: asynchronous liststo: asynchronous AND-OR lists On page 2409 line 77104 section 2.14 set (-b), change: It shall cause the shell to notify the user asynchronously of background job completions. The following message is written to standard error:to: When job control and -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 option shall have no effect. Asynchronous notification shall not be enabled by default. On page 2410 line 77149 section 2.14 set (-m), change: 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 jobs 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.to: 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. On page 2539 line 82126 section bg, change: If job control is enabled (see the description of set -m), the bg utility shall resume suspended jobs from the current environment (see [xref to 2.12]) by running them as background jobs.to: If job control is enabled (see the description of set -m), the shell is interactive, and the current shell execution environment (see [xref to 2.12]) is not a subshell environment, the bg 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. On page 2539 line 82130 section bg, delete: Using bg 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]. After page 2541 line 82206 section bg, add a new paragraph: The bg and fg utilities are not symmetric as regards the list of process IDs known in the current shell execution environment. Whereas fg removes a process ID from this list, bg 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]). On page 2786 line 91465 section fg, change: If job control is enabled (see the description of set -m), the fg utility shall move a background job from the current environment (see [xref to 2.12]) into the foreground.to: If job control is enabled (see the description of set -m), the shell is interactive, and the current shell execution environment (see [xref to 2.12]) is not a subshell environment, the fg 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. On page 2787 line 91507 section fg (EXIT STATUS), change: The following exit values shall be returned:to: If the fg utility succeeds, it does not return an exit status. Instead, the shell waits for the job that fg moved into the foreground. On page 2870 line 94571 section jobs, change: in the current sessionto: in the current shell execution environment On page 2870 line 94575 section jobs, change: The jobs utility shall display the status of jobs that were started in the current shell environment; see [xref to 2.12].to: If the current shell execution environment (see [xref to 2.12]) is not a subshell environment, the jobs 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. On page 2870 line 94583 section jobs (-l), change: This information shall include the job number, current job, process group ID, state, and the command that formed the job.to: See STDOUT for details. On page 2870 line 94586 section jobs (-p), change: Display only the process IDs for the process group leaders of the selected jobs.to: 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). On page 2870 line 94587 section jobs, change: shall display the status of all stopped jobs, running background jobs and all jobs whose status has changedto: shall display the status of all background jobs, both running and suspended, and all jobs whose status has changed On page 2871 line 94629 section jobs, change: process groupto: job On page 2871 line 94652 section jobs, change: If the -l option is specified, a field containing the process group ID shall be inserted before the <state> field. Also, more processes in a process group may be output on separate lines, using only the process ID and <command> fields.to: If the -l option is specified: On page 2872 line 94668 section jobs, change: the process group of a jobto: the process group of a job-control background job On page 2872 line 94687 section jobs, change: The jobs utility is not dependent on the job control option, as are the seemingly related bg and fg utilities because jobs is useful for examining background jobs, regardless of the condition of job control. When the user has invoked a set +m command and job control has been turned off, jobs can still be used to examine the background jobs associated with that current session. Similarly, kill can then be used to kill background jobs with kill %<background job number>.to: The jobs utility is not dependent on job control being enabled, as are the seemingly related bg and fg utilities, because jobs is useful for examining background jobs, regardless of the current state of job control. When job control has been disabled using set +m, jobs 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 kill() and wait(). On page 2879 line 94945 section kill, change: ... process that was terminated by a signal, the signal_name corresponding to the signal that terminated the process shall be written.to: ... process that was terminated or stopped by a signal, the signal_name corresponding to the signal that terminated or stopped the process shall be written. On page 2880 line 94987 section kill, change: 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 kill in the current shell execution environment; see [xref to 2.12].to: 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 kill in the current shell execution environment; see [xref to 2.12]. After page 2883 line 95095 section kill, add a new paragraph: The use of job ID notation is not dependent on job control being enabled. When job control has been disabled using set +m, kill 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 kill %<background job number> See also the RATIONALE for jobs() and wait(). On page 3430 line 115763 section wait, change: 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].to: The wait 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. On page 3430 line 115773 section wait, change: The known process IDs are applicable only for invocations of wait in the current shell execution environment.to: 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. On page 3430 line 115780 section wait, change: The unsigned decimal integer process ID of a command, for which the utility is to wait for the termination.to: The unsigned decimal integer process ID of a child process whose termination the utility is to wait for. On page 3430 line 115782 section wait, change: 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 wait in the current shell execution environment; see [xref to 2.12]. The exit status of wait shall be determined by the last command in the pipeline.to: 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 wait in the current shell execution environment; see [xref to 2.12]. The exit status of wait shall be determined by the exit status of the last pipeline to be executed. On page 3431 line 115818 section wait, change: 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.to: 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. On page 3431 line 115828 section wait, change: The command identified by the last pid operand specified is unknown.to: The process ID specified by the last pid operand is not known in the invoking shell execution environment. After page 3431 line 115838 section wait, add a new paragraph: The use of job ID notation is not dependent on job control being enabled. When job control has been disabled using set +m, wait 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 wait %<background job number> See also the RATIONALE for jobs() and kill(). On page 3431 line 115839-115853 section wait, delete the text that begins with: Historical implementations of interactive shells have discarded ... and ends with: ... work without losing status on any of the jobs. On page 3432,3433 line 115857,115858,115859,115863,115896 section wait, change: asynchronousto: asynchronous AND-OR On page 3432 line 115868 section wait, add a new paragraph: Some historical shells returned from wait when a process stops instead of only when it terminates. This standard does not allow wait to return when a process stops for two reasons: On page 3433 line 115904 section wait, change FUTURE DIRECTIONS from: None.to: A future version of this standard may add an option which takes a variable name as an option-argument, allowing wait to return information about the wait status of a process in an unambiguous way. On page 3494 line 118117 section A.3 Definitions (Job Control), change: which causes the foreground job to stop and the shell to begin prompting for new commands. The stopped job can be ...to: 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 ... On page 3494 line 118121 section A.3 Definitions (Job Control), change: 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.to: 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. On page 3494 line 118124 section A.3 Definitions (Job Control), change: can continue the stopped job in the foregroundto: can continue the suspended job in the foreground On page 3494 line 118128 section A.3 Definitions (Job Control), change: The interactive interface described previously can be accomplished using the POSIX.1 job control facilities in the following way.to: 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. On page 3494 line 118134 section A.3 Definitions (Job Control), change: The shell places each job in a separate process group via the setpgid() function.to: The shell places the process(es) it creates for each job in a separate process group via the setpgid() function. On page 3495 line 118144 section A.3 Definitions (Job Control), change: all processes in the pipeline (job)to: all processes in the job On page 3495 line 118146 section A.3 Definitions (Job Control), delete: The shell itself is considered to be a job and is the sole process in its own process group. On page 3495 line 118154 section A.3 Definitions (Job Control), change: The shell, in turn, informs the terminal I/O driver via the tcsetpgrp() 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 tcsetpgrp() 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 tcsetpgrp() to move a process group (job) into the foreground.to: The shell, in turn, informs the terminal I/O driver via the tcsetpgrp() 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 tcsetpgrp() 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 tcsetpgrp() to move a process group into the foreground. On page 3495 line 118167 section A.3 Definitions (Job Control), change: 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 tcsetpgrp() to place the job in the foreground before sending SIGCONT.to: 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 tcsetpgrp() to place the process group in the foreground before sending SIGCONT. On page 3495 line 118175 section A.3 Definitions (Job Control), change: 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.to: 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. On page 3495 line 118184 section A.3 Definitions (Job Control), change: 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 foregroundto: 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 On page 3495 line 118187 section A.3 Definitions (Job Control), change: 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.to: 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. On page 3496 line 118196 section A.3 Definitions (Job Control), change: 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 ...to: 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 ... On page 3742 line 128447 section C.2.9.3 Lists, change: Asynchronous Liststo: Asynchronous AND-OR Lists On page 3742 line 128458 section C.2.9.3 Lists, change: asynchronous liststo: asynchronous AND-OR lists On page 3742 line 128466 section C.2.9.3 Lists, change: Sequential Liststo: Sequential AND-OR Lists On page 3747 line 128643 section C.2, add a new subsection: C.2.11 Job Control See also [xref to Job Control subsection of A.3 Definitions].and renumber the later subsections. |
(0005888) geoffclare (manager) 2022-07-14 15:50 |
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- Various aspects of asynchronous lists and job control are insufficiently specified in the standard. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes in Note: 0005845 |
(0005894) agadmin (administrator) 2022-07-18 15:18 |
Interpretation proposed: 18 July 2022 |
(0005958) agadmin (administrator) 2022-09-01 16:25 |
Interpretation Approved: 1 September 2022 |
![]() |
|||
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 | |
2022-06-06 09:51 | geoffclare | Note Edited: 0005845 | |
2022-07-14 15:50 | geoffclare | Note Added: 0005888 | |
2022-07-14 15:51 | geoffclare | Interp Status | => Pending |
2022-07-14 15:51 | geoffclare | Final Accepted Text | => Note: 0005888 |
2022-07-14 15:51 | geoffclare | Status | New => Interpretation Required |
2022-07-14 15:51 | geoffclare | Resolution | Open => Accepted As Marked |
2022-07-14 15:51 | geoffclare | Tag Attached: issue8 | |
2022-07-18 15:18 | agadmin | Interp Status | Pending => Proposed |
2022-07-18 15:18 | agadmin | Note Added: 0005894 | |
2022-09-01 16:25 | agadmin | Interp Status | Proposed => Approved |
2022-09-01 16:25 | agadmin | Note Added: 0005958 | |
2022-09-27 15:29 | geoffclare | Status | Interpretation Required => Applied |
2022-10-31 16:39 | geoffclare | Relationship added | has duplicate 0001611 |
2023-04-20 10:57 | geoffclare | Relationship added | related to 0001675 |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |