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


Groups > gnu.bash.bug > #15620 > unrolled thread

Re: bash loses control of jobs inside a command substitution

Started byChet Ramey <chet.ramey@case.edu>
First post2019-11-20 16:52 -0500
Last post2019-11-20 16:52 -0500
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

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

#15620 — Re: bash loses control of jobs inside a command substitution

FromChet Ramey <chet.ramey@case.edu>
Date2019-11-20 16:52 -0500
SubjectRe: bash loses control of jobs inside a command substitution
Message-ID<mailman.2114.1574286746.13325.bug-bash@gnu.org>
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/

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web