Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14810 > unrolled thread
| Started by | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| First post | 2018-11-13 09:59 -0500 |
| Last post | 2018-11-13 09:59 -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.
Re: Strange behaviour from jobs -p in a subshell Chet Ramey <chet.ramey@case.edu> - 2018-11-13 09:59 -0500
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Date | 2018-11-13 09:59 -0500 |
| Subject | Re: Strange behaviour from jobs -p in a subshell |
| Message-ID | <mailman.3979.1542121206.1284.bug-bash@gnu.org> |
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 -- ``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/
Back to top | Article view | gnu.bash.bug
csiph-web