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

Robert Elz <[email protected]>
Newsgroups gmane.comp.shells.bash.bugs
Message-ID <[email protected]>
    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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.