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


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

Re: Strange behaviour from jobs -p in a subshell

Started byGreg Wooledge <wooledg@eeg.ccf.org>
First post2018-11-13 10:09 -0500
Last post2018-11-13 10:09 -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: Strange behaviour from jobs -p in a subshell Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-13 10:09 -0500

#14811 — Re: Strange behaviour from jobs -p in a subshell

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2018-11-13 10:09 -0500
SubjectRe: Strange behaviour from jobs -p in a subshell
Message-ID<mailman.3981.1542122776.1284.bug-bash@gnu.org>
On Tue, Nov 13, 2018 at 09:59:51AM -0500, Chet Ramey wrote:
> On 11/13/18 4:28 AM, Christopher Jefferson wrote:
> > Consider the following script. While the 3 sleeps are running, both jobs 
> > -p and $(jobs -p) will print 3 PIDs. Once the 3 children are finished, 
> > jobs -p will continue to print the 3 PIDs of the done Children, but 
> > $(jobs -p) will only print 1 PID. $(jobs -p) always seems to print at 
> > most 1 PID of a done child.
> 
> Since the $(jobs -p) is run in a subshell, its knowledge of its parent's
> jobs is transient. In this case, the subshell deletes knowledge of the
> jobs it inherits from its parent, but hangs onto the last asynchronous job
> in case the subshell references $!.
> 
> Chet

If the goal is to obtain the result of "jobs -p" and use it in a script,
I would suggest redirecting the output of jobs -p to a temp file, then
reading it.  That skips the subshell.

[toc] | [standalone]


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


csiph-web