Re: `wait` triggers an infinite loop when used in an EXIT trap

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/