problem piping output of shell builtin

problem piping output of shell builtin

[gj]

Hi all,

I'm migrating from bash to zsh. It hasn't been so bad because I'm sort of new
to shell programming anyways ( though I did have "fun" figuring out that zsh
arrays start incrementing from 1 as opposed to bash's 0 :). I thought I'd
share the latest hiccup...

Why can't I pipe the output of 'jobs' thusly?

	% zsh --version
	zsh 4.0.7 (alpha--netbsd)
	% sleep 100
	^Z
	zsh: suspended  sleep 100
	% sleep 100
	^Z
	zsh: suspended  sleep 100
	% jobs
	[1]    suspended  pine
	[2]  - suspended  sleep 100
	[3]  + suspended  sleep 100
	% jobs | while read line; do echo $line; done
	%

I expect the output of last sequence of commands to be more or less the same
to the sequence before it, as under bash. How can I approximate the bashlike
behavior I expect under zsh?

Thanks for any insight,
Gerald.

Re: problem piping output of shell builtin

[Pavol Juhas]

On Mon, Jan 05, 2004 at 07:26:15PM +0000, gj@sdf.lonestar.org wrote:
> Hi all,
> 
> I'm migrating from bash to zsh. It hasn't been so bad because I'm sort of new
> to shell programming anyways ( though I did have "fun" figuring out that zsh
> arrays start incrementing from 1 as opposed to bash's 0 :). I thought I'd
> share the latest hiccup...
> 
> Why can't I pipe the output of 'jobs' thusly?

AFAIK, all the shells run one side of the pipe in a subshell.  bash
executes subshell for the right side of the pipe, however zsh does
so for the left side.  Therefore the `jobs' command in 
`jobs|read line' is evaluated in the subshell of zsh, which has no
knowledge about processes in the parent shell - and produces no
output.  Left side subshell is however advantageous in other
situations, just compare

  zsh -c 'echo 10|read a; echo .$a'
  .10
  bash -c 'echo 10|read a; echo .$a' 
  .

To access information in the zsh job table, you need to use the
builtin associate arrays jobtexts, jobstates and jobdirs, for example:

  for j in ${(k)jobstates}; do
    print -- "[$j] ${jobstates[$j]} ${jobtexts[$j]} in ${jobdirs[$j]}"
  done

HTH,

Pavol

Re: problem piping output of shell builtin

[Vincent Stemen]

On Mon, Jan 05, 2004 at 07:26:15PM +0000, gj@sdf.lonestar.org wrote:
> Hi all,
> 
> I'm migrating from bash to zsh. It hasn't been so bad because I'm sort of new
> to shell programming anyways ( though I did have "fun" figuring out that zsh
> arrays start incrementing from 1 as opposed to bash's 0 :). I thought I'd
> share the latest hiccup...
> 
> Why can't I pipe the output of 'jobs' thusly?
> 
> 	% zsh --version
> 	zsh 4.0.7 (alpha--netbsd)
> 	% sleep 100
> 	^Z
> 	zsh: suspended  sleep 100
> 	% sleep 100
> 	^Z
> 	zsh: suspended  sleep 100
> 	% jobs
> 	[1]    suspended  pine
> 	[2]  - suspended  sleep 100
> 	[3]  + suspended  sleep 100
> 	% jobs | while read line; do echo $line; done
> 	%
> 
> I expect the output of last sequence of commands to be more or less the same
> to the sequence before it, as under bash. How can I approximate the bashlike
> behavior I expect under zsh?
> 
> Thanks for any insight,
> Gerald.

That's interesting.  I get the same result as you on zsh-4.0.9 but
when I tried it on zsh-4.1.0-dev-5 it works properly.

<test>
$ zsh --version 
zsh 4.1.0-dev-5 (i386-portbld-freebsd5.0)
$ sleep 100
^Z
zsh: suspended  sleep 100
$ sleep 100
^Z
zsh: suspended  sleep 100
$ jobs | while read line; do echo $line; done
[1]  - suspended  sleep 100
[2]  + suspended  sleep 100
$
</test>

However, if I pipe the output of some other command like "ls", to the
while loop, it works fine.  The problem seems to only be when piping
the output of jobs.

Vincent

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
http://www.InetAddresses.net

Re: problem piping output of shell builtin

[Vincent Stemen]

On Mon, Jan 05, 2004 at 03:36:38PM -0500, Pavol Juhas wrote:
> On Mon, Jan 05, 2004 at 07:26:15PM +0000, gj@sdf.lonestar.org wrote:
> > Hi all,
> > 
> > I'm migrating from bash to zsh. It hasn't been so bad because I'm sort of new
> > to shell programming anyways ( though I did have "fun" figuring out that zsh
> > arrays start incrementing from 1 as opposed to bash's 0 :). I thought I'd
> > share the latest hiccup...
> > 
> > Why can't I pipe the output of 'jobs' thusly?
> 
> AFAIK, all the shells run one side of the pipe in a subshell.  bash
> executes subshell for the right side of the pipe, however zsh does
> so for the left side.  Therefore the `jobs' command in 
> `jobs|read line' is evaluated in the subshell of zsh, which has no
> knowledge about processes in the parent shell - and produces no
> output.  Left side subshell is however advantageous in other
> situations, just compare
> 
>   zsh -c 'echo 10|read a; echo .$a'
>   .10
>   bash -c 'echo 10|read a; echo .$a' 
>   .
> 
> To access information in the zsh job table, you need to use the
> builtin associate arrays jobtexts, jobstates and jobdirs, for example:
> 
>   for j in ${(k)jobstates}; do
>     print -- "[$j] ${jobstates[$j]} ${jobtexts[$j]} in ${jobdirs[$j]}"
>   done
> 
> HTH,
> 
> Pavol

Under bash, at least, the semi-colon is ending the pipe command and
then executing "echo .$a" as new command in the original shell.  So
you need to group the entire right side in the above example.
ie.

$ echo 10 | (read a; echo .$a)
.10
$

That is interesting.  I did not know zsh did that by default.
However, I am not sure you are correct about zsh forking a sub-shell
for the left side of the pipe.  If so, then local shell variables from
the parent shell should not be accessible unless they are exported,
but they are.

$ x=foo 
$ echo $x | read a; echo .$a
.foo
$

Vincent

-- 
Vincent Stemen
Avoid the VeriSign/Network Solutions domain registration trap!
http://www.InetAddresses.net

Re: problem piping output of shell builtin

[Bart Schaefer]

This is becoming a very FAQ, right up there with "why can't I see the last
line of my output when it doesn't end in a newline?"  I'm not sure why it
has never gotten an actual FAQ entry of its own.

Here's a short answer:

http://www.zsh.org/mla/workers/2003/msg00827.html

Try a search of the mailing list archives:

http://www.zsh.org/cgi-bin/mla/wilma_glimpse/workers?query=pipe%3Bjobs&Search=Search&restricttofiles=on&filelist=2003&filelist=2002&errors=0&maxfiles=50&maxlines=10&.cgifields=filelist&.cgifields=restricttofiles&.cgifields=lineonly&.cgifields=partial&.cgifields=case

http://www.zsh.org/cgi-bin/mla/wilma_glimpse/users?query=pipe%3Bjobs&Search=Search&restricttofiles=on&filelist=2003&filelist=2002&errors=0&maxfiles=50&maxlines=10&.cgifields=filelist&.cgifields=restricttofiles&.cgifields=lineonly&.cgifields=partial&.cgifields=case

Re: problem piping output of shell builtin

[Pavol Juhas]

On Mon, Jan 05, 2004 at 03:30:10PM -0600, Vincent Stemen wrote:
> On Mon, Jan 05, 2004 at 03:36:38PM -0500, Pavol Juhas wrote:
> > On Mon, Jan 05, 2004 at 07:26:15PM +0000, gj@sdf.lonestar.org wrote:
...
> > > Why can't I pipe the output of 'jobs' thusly?
> > 
> > AFAIK, all the shells run one side of the pipe in a subshell.  bash
> > executes subshell for the right side of the pipe, however zsh does
> > so for the left side.  Therefore the `jobs' command in 
> > `jobs|read line' is evaluated in the subshell of zsh, which has no
> > knowledge about processes in the parent shell - and produces no
> > output.  Left side subshell is however advantageous in other
> > situations, just compare
> > 
> >   zsh -c 'echo 10|read a; echo .$a'
> >   .10
> >   bash -c 'echo 10|read a; echo .$a' 
> >   .
...
> 
> Under bash, at least, the semi-colon is ending the pipe command and
> then executing "echo .$a" as new command in the original shell.  So
> you need to group the entire right side in the above example.
> ie.
> 
> $ echo 10 | (read a; echo .$a)
> .10
> $

Exactly, bash has no way to read the output of the pipe to a
variable (well, without creating temporary file).

> 
> That is interesting.  I did not know zsh did that by default.
> However, I am not sure you are correct about zsh forking a sub-shell
> for the left side of the pipe.  If so, then local shell variables from
> the parent shell should not be accessible unless they are exported,
> but they are.
> 
> $ x=foo 
> $ echo $x | read a; echo .$a
> .foo
> $

Variables are exported to the subshell, but if you change them in
the left-side of the pipe, they will keep the original value in the
parent shell, e.g.

  $ a=foo; { a=bar } | :
  $ echo $a
  foo

  $ a=foo; { a=bar }
  $ echo $a
  bar

  $ a=foo; : | { a=bar }
  $ echo $a
  bar

  $ i=foo; for i in 1 2; do echo $i; done | cat; echo $i
  1
  2
  foo

I think the most recent versions of zsh were expanded so they
actually can handle `jobs|read line'.

Pavol