The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=1254
======================================================================
Reported By: stephane
Assigned To:
======================================================================
Project: 1003.1(2016)/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: 2019-06-08 09:14 UTC
======================================================================
Summary: "asynchronous list" description uses "command"
instead of "AND-OR list"
Description:
That's a follow-up on my http://austingroupbugs.net/view.php?id=760#c4410
comment on http://austingroupbugs.net/view.php?id=760.
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
"$!")
======================================================================
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 ($!)
======================================================================
