Date: Mon, 5 Jan 2026 11:50:24 -0500
From: Chet Ramey <[email protected]>
Message-ID: <[email protected]>
| The child process, which has an active EXIT trap, has inherited the jobs
| array,
That seems wrong to me - the jobs array (list of children) of the parent
cannot possibly be the list of children of the child after a fork.
I know that keeping the jobs table around in the child is needed for uses like
x=$(jobs)
(just like the traps are for trap) but it should only be valid for that
purpose, any other use of it at all (starting a new process, waiting, ...)
should empty the old (now irrelevant) jobs table before continuing. Only
the jobs command (and else anything functionally the same, if there is
something like that in bash) should be able to see anything from the parent
after forking.
I can't see any conceivable valid reason to keep the jobs table data
around in children (after anything except a jobs command is about to be
run) so this should be able to be fixed without bothering about compat
issues (certainly nothing in a sub-shell can ever wait for anything started
in the parent).
Beyond that, this:
It then exits and runs its exit trap before the child process
runs and resets its EXIT trap handler.
should not be possible either. It looks like an unavoidable race, but
it needn't be. The traps just need to be linked to the current pid,
if the pid of the process which receives a signal is not the same as the
pid of the owner of the traps, then the traps should all be reset, as would
have happened in the child if the signal had not occurred so quickly, before
attempting to run any associated traps. The child should simply reset
the traps as it normally would (which includes taking ownership of the traps
table, after it has been reset as required), then send the signal it received
to itself so the correct thing happens.
kre
