[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash loses control of jobs inside a command substitution

From: Chet Ramey
Subject: Re: bash loses control of jobs inside a command substitution
Date: Wed, 20 Nov 2019 16:52:19 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 11/19/19 2:51 PM, Luiz Angelo Daros de Luca wrote:

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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]