[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange behaviour from jobs -p in a subshell

From: Christopher Jefferson
Subject: Re: Strange behaviour from jobs -p in a subshell
Date: Wed, 14 Nov 2018 09:48:49 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

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.

This originally came up as I was implementing a poor way of limiting how 
many background processes I spawn, by doing:

     while (( $(jobs -p | wc -l) >= $JOBCOUNT ))
             sleep 1

Here, the $(jobs -p | wc -l) decreases to 1 as jobs finish, but never 
reaches 0.

I've now changed 'sleep 1' to 'jobs > /dev/null; sleep 1'.

I can't find any documentation that says this, but it seems 'jobs' will 
clean up children which are done, which 'jobs -p' does not (this makes 
sense of course, as jobs -p doesn't report if a child is done, but I 
still can't find it documented anywhere).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]