Date: Tue, 6 Jan 2026 15:01:35 -0500
From: Chet Ramey <[email protected]>
Message-ID: <[email protected]>
| It's the inconsistency in the description: the first sentence says to
| wait for "child processes" (which is defined)
It is, but the definition is nothing special - just a process
created by fork() (etc) by the "given process" which isn't
specified here (in wait). What's more, the shell spec goes to
great lengths to distinguish between execution environments, and
processess which complicates all of this.
That is, it isn't required that the shell forks, when a new
execution environment is created, that can be done other ways
(forking is the easy way) as long as the semantics are preserved.
We wouldn't want a non-forking subshell env to be able to wait
for a child of its parent environment, even if the process semantics
would allow that to work.
| 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.
Maybe. And we all know what is (must be) intended to happen - nothing
(except init) should be able to wait for any process it didn't create,
it is all just in how the wording gets changed to make that apparent.
| 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?
No, which is why I'd certainly be changing the definition of the initial
setup of a new subshell environment, to make it clear that the jobs
list is to be cleared (with the exception of allowing jobs, and any other
similar commands, to access the parent's table for reporting purposes,
as is done for trap - the two are really very similar cases).
That is, in preference to fudging the wording in wait (and anywhere
else there might be similar issues - like bg fg (which only operate
on jobs known in the current execution environment -- they're not
required to work in subshell environments, but are permitted to.
When they do, we wouldn't want (or expect) a subshell to be able to
move a job between foreground and background in its parent envioronment,
and doing so in its own environment would be nonsense.)
There's also the question of changes to the list of known jobs in
a subshell environment and what effect that has upon the parent's
environment. In general, subshells cannot affect the parent at all
(other than via i/o etc, and the status they return when done).
The easy way to fix this, to me, seems to be to do the obvious thing
and make the list of known jobs something which is perhaps available
in a child environment, but which is not a list of known jobs there,
just random data from the parent.
kre
