Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14811
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Strange behaviour from jobs -p in a subshell |
| Date | 2018-11-13 10:09 -0500 |
| Message-ID | <mailman.3981.1542122776.1284.bug-bash@gnu.org> (permalink) |
| References | <b17b162c-9f60-37fc-2473-30e267a681d2@st-andrews.ac.uk> <563c6188-c905-db81-f330-b79bf17e4413@case.edu> |
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.
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: Strange behaviour from jobs -p in a subshell Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-13 10:09 -0500
csiph-web