On 1/5/26 5:30 PM, Robert Elz wrote:
     Date:        Mon, 5 Jan 2026 15:19:46 -0500
     From:        Chet Ramey <[email protected]>
     Message-ID:  <[email protected]>

   |  POSIX requires it without any qualifying language.

That has to be an oversight - perhaps partly caused by the jobs
command:
        it may also do so if the current shell execution environment
        is a subshell environment.

but if jobs from the parent are known in subshell environments, then
the wait command's:

        The wait utility shall wait for one or more child processes whose
        process IDs are known in the current shell execution environment
        (see Section 2.13, on page 2522) to terminate.

        If the wait utility is invoked with no operands, it shall wait until
        all process IDs known to the invoking shell have terminated and exit
        with a zero exit status.

become unimplementable - how is the child process possibly supposed to
discover when children of the parent have exited (and return their
exit status when pid args are given) ?   Just discovering they have
exited could be done with a kill(pid, 0) polling loop, but there's
no way to get the status that way, and:

        The exit status returned by the wait utility shall be the exit
        status of the process requested by the last pid operand.

That's a "shall" so it is required - if the pid is "known in ...",
if not the 127 status return applies.

It's the inconsistency in the description: the first sentence says to
wait for "child processes" (which is defined) but it goes on to use
"processes IDs are known in the current shell execution environment"
and and "known process IDs." I'd anticipate that the group would fall
back on the "well, it clearly says child processes, and we meant
child processes created in the current shell execution environment"
explanation to solve that.

The non-normative description of "wait" says there are "no known
process IDs in those [subshell] environments" (with a few examples
given), which implies that the shell discards the list of known process
IDs unless the first thing it does is run "jobs." But that doesn't seem
consistent with the definition of a subshell environment, does it?

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/

Reply via email to