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 might be interesting to see what the austin group has to say.
It would, will you ask them (I vanished off the list 18 months
ago, and haven't had the energy to work out how to get back on).
kre
