Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: bash loses control of jobs inside a command substitution
Date: Wed, 20 Nov 2019 16:52:19 -0500
Lines: 32
Approved: bug-bash@gnu.org
Message-ID: <mailman.2114.1574286746.13325.bug-bash@gnu.org>
References: <CAJq09z4OWeZchYVH9U1G2OuTzdXBh+F8gLEjkqcJemohzi8dDg@mail.gmail.com> <b1123507-d0d9-4503-283b-81c5b6d45f92@case.edu>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: chet.ramey@case.edu
To: Luiz Angelo Daros de Luca <luizluca@gmail.com>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
In-Reply-To: <CAJq09z4OWeZchYVH9U1G2OuTzdXBh+F8gLEjkqcJemohzi8dDg@mail.gmail.com>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:15620

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/