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

[Seb <sbb@xxxxxxxxxxxxx>]

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.

--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html