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


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

Re: Strange behaviour from jobs -p in a subshell

Started byChet Ramey <chet.ramey@case.edu>
First post2018-11-14 10:12 -0500
Last post2018-11-14 10:12 -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 Chet Ramey <chet.ramey@case.edu> - 2018-11-14 10:12 -0500

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

FromChet Ramey <chet.ramey@case.edu>
Date2018-11-14 10:12 -0500
SubjectRe: Strange behaviour from jobs -p in a subshell
Message-ID<mailman.4034.1542208411.1284.bug-bash@gnu.org>
On 11/14/18 4:48 AM, Christopher Jefferson wrote:
> 
> On 13/11/2018 14:59, 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 $!.
> 
> 
> Is this a case of "works as intended" then? I find the current behaviour 
> very strange -- I could understand if 'jobs -p' showed no information 
> about processes spawned from the parent shell, or all of it, but the 
> current position seems quite inconsistent.

Why? The shell has to keep the value and status of $! because POSIX says
you can always request it. A subshell inherits that pid, so it's `known'
to the subshell, and it will stick around until you get notfied of the
status. You don't restrict the `jobs -p' output to running jobs, so it's
going to show up, and you don't request the status of the job (even jobs
or jobs -l would be sufficient) so it's not going to go away.

-- 
``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