Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15620

Re: bash loses control of jobs inside a command substitution

Show key headers only | View raw

On 11/19/19 2:51 PM, Luiz Angelo Daros de Luca wrote:
> Hello,
> 
> Normally 'wait -n' will return the exit code of background process when
> they terminate before wait is runned. However, when bg processes and 'wait
> -n' runs inside a command substitution, bash loses control of bg process as
> soon as they exit.

This looks a lot like a race condition. If you run the sleep with a
non-zero argument (or, really, even if you don't, but the non-zero
sleep increases the odds), you have two chances -- the sleep and the
command substitution in the second loop -- for child processes to exit
and be reaped. Since they're asynchronous children, bash will save their
statuses, but they won't be available for a subsequent `wait -n' call.
They're not lost: you can fetch those statuses using wait with a pid
argument.

The difference is when jobs are moved from the `active jobs' list, where
they are available to `wait -n', into the `saved background processes'
list, where they are not, and that does differ based on whether the shell
thinks it will eventually notify the user about the job's exit status. When
the shell is started to run a command substitution, it knows it will not
have to notify the user about any jobs, so it's more aggressive about
moving jobs out of the jobs list.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: bash loses control of jobs inside a command substitution Chet Ramey <chet.ramey@case.edu> - 2019-11-20 16:52 -0500

csiph-web