`jobs -p` does not behave as documented and required by POSIX

`jobs -p` does not behave as documented and required by POSIX

[Matthias Richerzhagen]

Hello,

the manpage for the `jobs` buildin function states:

>       −p        Display only the process IDs for the process group
>       leaders of the selected jobs.

> STDOUT
>        If the −p option is specified, the output shall consist of one
> line for each process ID:
> 
>            "%d\n", <process ID>

From the command:

    ( sleep 5; echo 1 ) & ( sleep 10; echo 2 ) &; jobs -p

one can see, that the output does NOT only display the process IDs:

    [1]  - 9282 running    ( sleep 5; echo 1; )
    [2]  + 9283 running    ( sleep 10; echo 2; )

making the usage in commands like

    kill `jobs -p`

generate a lot of error messages.

This is with 

    $ zsh --version 
    zsh 5.4.2 (x86_64-unknown-linux-gnu)

on Arch Linux.

Greetings,
Matthias

Re: `jobs -p` does not behave as documented and required by POSIX

[Peter Stephenson]

On Wed, 20 Dec 2017 08:56:20 +0100
Matthias Richerzhagen <matthias.richerzhagen@alumni.fh-aachen.de> wrote:
> Hello,
> 
> the manpage for the `jobs` buildin function states:
> 
> >       −p        Display only the process IDs for the process group
> >       leaders of the selected jobs.
> 
> > STDOUT
> >        If the −p option is specified, the output shall consist of one
> > line for each process ID:
> > 
> >            "%d\n", <process ID>

Erm, I don't think you're looking at the right manual...

       jobs [ -dlprs ] [ job ... ]
       jobs -Z string
              Lists information about each given job, or all jobs  if  job  is
              omitted.   The  -l flag lists process IDs, and the -p flag lists
              process groups.  If the -r flag is specified only  running  jobs
              will be listed and if the -s flag is given only stopped jobs are
              shown.  If the -d flag is given, the directory  from  which  the
              job  was  started (which may not be the current directory of the
              job) will also be shown.

              The -Z option replaces  the  shell's  argument  and  environment
              space  with  the  given  string,  truncated if necessary to fit.
              This will normally be visible in ps (ps(1)) listings.  This fea‐
              ture is typically used by daemons, to indicate their state.

There's no mention of *only* listing process groups.

pws

Re: `jobs -p` does not behave as documented and required by POSIX

[Eric Pruitt]

On Wed, Dec 20, 2017 at 09:45:49AM +0000, Peter Stephenson wrote:
> On Wed, 20 Dec 2017 08:56:20 +0100
> Matthias Richerzhagen <matthias.richerzhagen@alumni.fh-aachen.de> wrote:
> > Hello,
> >
> > the manpage for the `jobs` buildin function states:
> >
> > >       −p        Display only the process IDs for the process group
> > >       leaders of the selected jobs.
> >
> > > STDOUT
> > >        If the −p option is specified, the output shall consist of one
> > > line for each process ID:
> > >
> > >            "%d\n", <process ID>
>
> Erm, I don't think you're looking at the right manual...

The text Matthias is quoting is from the POSIX specification
(http://pubs.opengroup.org/onlinepubs/009695399/utilities/jobs.html). I
think their point is moot though because Z-shell does not claim to be
POSIX compliant in its default mode. That said, when running Z-shell as
"sh", the output of `jobs -p` still includes the "extra" information:

    ~$ (exec -a sh zsh -c 'sleep 1 & sleep 2 & jobs -p')
    [1]  - 1022 running    sleep 1
    [2]  + 1023 running    sleep 2

Eric

Re: `jobs -p` does not behave as documented and required by POSIX

[dana]

On 20 Dec 2017, at 04:42, Eric Pruitt <eric.pruitt@gmail.com> wrote:
>think their point is moot though because Z-shell does not claim to be
>POSIX compliant in its default mode. That said, when running Z-shell as
>"sh", the output of `jobs -p` still includes the "extra" information:

Seems this was brought up before (linked from workers/22180); Bart had some
thoughts about it but no action was taken:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346162

Anyway, as a work-around one can do this:

  kill ${${jobstates#*:*:}%=*}

Or in a script it's probably sufficient most of the time to kill the shell's
entire process group (maybe `-HUP` would be a little nicer):

  kill 0

dana