Inconsistent behaviour between 'jobs' and 'echo "$(jobs)"'

Inconsistent behaviour between 'jobs' and 'echo "$(jobs)"'

[Damian Wrobel]

Hi,

I'm observing an inconsistent behaviour between:
  jobs
and
  echo "$(jobs)"

Here is the short example:

$ rpm -qv dash
dash-0.5.8-1.fc21.i686
$ /bin/dash
$ sleep 1000 &
$ jobs
[1] + Running                    sleep 1000
$ echo "$(jobs)"

$ echo `jobs`

$ jobs 2>/dev/null
[1] + Running                    sleep 1000
$

-- 
Have a nice day,
Damian

Re: Inconsistent behaviour between 'jobs' and 'echo "$(jobs)"'

[Damian Wrobel]

On 01/20/2015 09:44 AM, Seb wrote:
> On Mon, Jan 19, 2015 at 07:01:53PM +0100, Damian Wrobel wrote:
>
> Hello,
>
>> I'm observing an inconsistent behaviour between:
>>   jobs
>> and
>>   echo "$(jobs)"
>
> It's because the command is ran in a sub-shell, where there is indeed no
> running job.
>
> Bash has a special mechanism to handle this and get the current shell
> context returned, that's why you may feel some inconsistency here (like
> I myself did :)

There is an application usage [1] where this case is specifically mentioned with 
a suggestion that: "For this reason, jobs is generally implemented as a shell 
regular built-in."

I basically planned to use the following construction to kill all running jobs:

$ kill $(jobs -p)

Now it looks that even the following doesn't work in a dash:

$ jobs -p | xargs kill

I would prefer not to code something like the following:

$ jobs -p >/tmp/jobs-$$ && kill $(cat /tmp/jobs-$$); rm /tmp/jobs-$$


Have a nice day,
Damian

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/jobs.html

>
> ++
> Seb.
>
>
>

Re: Inconsistent behaviour between 'jobs' and 'echo "$(jobs)"'

[Seb]

On Tue, Jan 20, 2015 at 06:01:10PM +0100, Damian Wrobel wrote:
> On 01/20/2015 09:44 AM, Seb wrote:
> >On Mon, Jan 19, 2015 at 07:01:53PM +0100, Damian Wrobel wrote:
> >
> >Hello,
> >
> >>I'm observing an inconsistent behaviour between:
> >>  jobs
> >>and
> >>  echo "$(jobs)"
> >
> >It's because the command is ran in a sub-shell, where there is indeed no
> >running job.
> >
> >Bash has a special mechanism to handle this and get the current shell
> >context returned, that's why you may feel some inconsistency here (like
> >I myself did :)
> 
> There is an application usage [1] where this case is specifically mentioned
> with a suggestion that: "For this reason, jobs is generally implemented as a
> shell regular built-in."

Indeed, it seems the standard requires, or at least expects this to
work:

 "The -p option is the only portable way to find out the
  process group of a job because different implementations
  have different strategies for defining the process group of
  the job. Usage such as $(jobs -p) provides a way of
  referring to the process group of the job in an
  implementation-independent way."


> Now it looks that even the following doesn't work in a dash:
> 
> $ jobs -p | xargs kill

For the same reason as above: each member of the pipe is ran in its own
sub-shell.


> I would prefer not to code something like the following:
> 
> $ jobs -p >/tmp/jobs-$$ && kill $(cat /tmp/jobs-$$); rm /tmp/jobs-$$

I agree it's not very nice.

++
Seb.

Re: Inconsistent behaviour between 'jobs' and 'echo "$(jobs)"'

[Seb]

On Tue, Jan 20, 2015 at 06:01:10PM +0100, Damian Wrobel wrote:
> I would prefer not to code something like the following:
> 
> $ jobs -p >/tmp/jobs-$$ && kill $(cat /tmp/jobs-$$); rm /tmp/jobs-$$

As a better alternative, you could maybe try this:
  
  trap : TERM # in case we have something to do after...
  /bin/kill -s TERM -$$

Just an idea...

++
Seb.