`jobs | wc -l' => 0 ... bug?

`jobs | wc -l' => 0 ... bug?

[Adam Spiers]

----- Forwarded message from Bostjan Muller <neonatus@neonatus.net> -----

Date: Fri, 23 Mar 2001 18:09:31 +0100
To: Adam Spiers <adam@spiers.net>
Subject: Re: the power of zsh
From: neonatus@neonatus.net (Bostjan Muller)
X-Parp-Accepted: had In-Reply-To: header

[snip]

Only one more thing.. I used to include a command in my prompt, that displayed
the number of background processes running I got the number with the following
command:
jobs | wc -l | tr -d " "
but in zsh wc does not seem to get any input:
$ jobs
[1]  - suspended  mc
[3]  + suspended  mc

$ jobs | wc -l
      0

Where in bash I get this:
$ jobs
[1]-  Stopped                 /usr/bin/mc $*
[2]+  Stopped                 /usr/bin/mc $*

$ jobs | wc -l
      2
----- End forwarded message -----

This is a bug, surely?

Re: `jobs | wc -l' => 0 ... bug?

[Peter Stephenson]

> From: neonatus@neonatus.net (Bostjan Muller)
> jobs | wc -l | tr -d " "
> but in zsh wc does not seem to get any input:
> $ jobs
> [1]  - suspended  mc
> [3]  + suspended  mc
> 
> $ jobs | wc -l
>       0

jobs here runs in a subshell, where there is no job control, so no
information on jobs.  It has always been this way.  It's not particularly
convenient, however.  Maybe it's time someone thought about changing it.

The only workaround is to use a temporary file for output.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: `jobs | wc -l' => 0 ... bug?

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

On Mon, Mar 26, 2001 at 04:18:10PM +0100,
Adam Spiers <adam@spiers.net> wrote:
> 
> ----- Forwarded message from Bostjan Muller <neonatus@neonatus.net> -----
> 
> Date: Fri, 23 Mar 2001 18:09:31 +0100
> To: Adam Spiers <adam@spiers.net>
> Subject: Re: the power of zsh
> From: neonatus@neonatus.net (Bostjan Muller)
> X-Parp-Accepted: had In-Reply-To: header
> 
> [snip]
> 
> Only one more thing.. I used to include a command in my prompt, that displayed
> the number of background processes running I got the number with the following
> command:
> jobs | wc -l | tr -d " "
> but in zsh wc does not seem to get any input:
> $ jobs
> [1]  - suspended  mc
> [3]  + suspended  mc
> 
> $ jobs | wc -l
>       0
> 
> Where in bash I get this:
> $ jobs
> [1]-  Stopped                 /usr/bin/mc $*
> [2]+  Stopped                 /usr/bin/mc $*
> 
> $ jobs | wc -l
>       2
> ----- End forwarded message -----
> 
> This is a bug, surely?

Well, it's not what one would expect (and the section about "jobs" in
"man zshbuiltins" doesn't mention such behaviour), so you might call it
a bug.

Of course, you can still use $jobstates for many things. Tried that?

Ciao,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: `jobs | wc -l' => 0 ... bug?

[Bart Schaefer]

On Mar 26,  3:29pm, Peter Stephenson wrote:
} Subject: Re: `jobs | wc -l' => 0 ... bug?
}
} > $ jobs | wc -l
} >       0
} 
} jobs here runs in a subshell, where there is no job control, so no
} information on jobs.  It has always been this way.  It's not particularly
} convenient, however.  Maybe it's time someone thought about changing it.

What do you suggest, that we special-case the "jobs" command?

Zsh runs the left-hand-side of pipelines in a subshell and the right-
hand-side in a current shell so that stuff like

	echo foo | read line
	echo $line

will output "foo".  Bash (I believe) runs the right-hand-side in a subshell
and the left in the current shell.  I like zsh's way better.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: `jobs | wc -l' => 0 ... bug?

[Peter Stephenson]

> On Mar 26,  3:29pm, Peter Stephenson wrote:
> } Subject: Re: `jobs | wc -l' => 0 ... bug?
> }
> } > $ jobs | wc -l
> } >       0
> } 
> } jobs here runs in a subshell, where there is no job control, so no
> } information on jobs.  It has always been this way.  It's not particularly
> } convenient, however.  Maybe it's time someone thought about changing it.
> 
> What do you suggest, that we special-case the "jobs" command?

Clearing the job table is handled specially in entersubsh().

    if (cl)
	clearjobtab();

MONITOR gets unset at this point, too.  It shouldn't be necessary to do
both, and it should be possible to hack bin_fg() so that it can still list
jobs even if it can't control them.  In fact, it looks like this is half
there: `fg' and `bg' test for !jobbing and complain, whereas `jobs'
doesn't and silently scans the empty job list.  So maybe not clearing the
job table and relying on the option setting just works.  But it needs a
proper work through to make sure.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: `jobs | wc -l' => 0 ... bug?

[Adam Spiers]

Thanks for all your replies; I've pointed the guy who asked
originally in their direction.

$jobstates is probably good enough for him, so unless it's easy to
special-case `jobs' I would have thought documenting the problem would
be sufficient.

Re: `jobs | wc -l' => 0 ... bug?

[Sven Wischnowsky]

Peter Stephenson wrote:

> > From: neonatus@neonatus.net (Bostjan Muller)
> > jobs | wc -l | tr -d " "
> > but in zsh wc does not seem to get any input:
> > $ jobs
> > [1]  - suspended  mc
> > [3]  + suspended  mc
> > 
> > $ jobs | wc -l
> >       0
> 
> jobs here runs in a subshell, where there is no job control, so no
> information on jobs.  It has always been this way.  It's not particularly
> convenient, however.  Maybe it's time someone thought about changing it.
> 
> The only workaround is to use a temporary file for output.

But in zsh one can do that faster with ${#jobdirs} (or jobstates or
jobtexts) anyway.  After the parameter module is loaded.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de