Re: zsh-3.1.5 released

Re: zsh-3.1.5 released

[Geoff Wing]

coordinator@zsh.org <coordinator@zsh.org> typed:
[...stuff deleted...]
:To subscribe, send mail with the SUBJECT `subscribe <e-mail-address>'
:to the associated administrative address for the mailing list.
:      <zsh-announce-request@math.gatech.edu>
:      <zsh-users-request@math.gatech.edu>
:      <zsh-workers-request@math.gatech.edu>
[...stuff deleted...]
:The mailing lists are archived; the archives can be accessed via the
:administrative addresses listed above.
                                      ^^^
You should probably add ``with a Subject starting with the word "archive".
Help can be obtained by putting the word "help" in the message body''.

Otherwise, I suspect that Richard Coleman will have to manually handle them.

Regards,
-- 
Geoff Wing   <gcw@pobox.com>            Mobile : 0412 162 441
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

jobs command and pipes

[Owen M. Astley]

Why is it that the jobs command in zsh will not work with a pipe, although
redirecting it to a file does work?

Owen

Re: jobs command and pipes

[Zefram]

Owen M. Astley wrote:
>Why is it that the jobs command in zsh will not work with a pipe, although
>redirecting it to a file does work?

If the jobs command is on the left hand side of a pipeline, the shell has
to fork, and the jobs builtin runs in the forked process.  This process
is not in control of any jobs, so the jobs command has nothing to report.

-zefram

Re: jobs command and pipes

[Bruce Stephens]

"Owen M. Astley" <oma1000@cam.ac.uk> writes:

> Why is it that the jobs command in zsh will not work with a pipe,
> although redirecting it to a file does work?

>From a practical point of view, it's surely obvious.  You can
implement

	A | B

by forking twice, redirecting I/O appropriately in the two children,
and then one child executes A, and one executes B.  I suspect

	jobs | wc

*does* work.  But the child process shell which executes the builtin
jobs doesn't have any jobs, so the result isn't interesting.

	jobs > foo

doesn't require jobs to be executed in a subshell, so it'll work as
expected.  (i.e., you get the list of jobs in the current shell,
rather than the empty list of jobs in a newly forked shell.)

So I think it's logical; probably a feature rather than a bug.  If
it's a bug, I wouldn't expect a fix soon.

Re: jobs command and pipes

[Stefan Monnier]

>>>>> "Zefram" == Zefram  <zefram@tao.co.uk> writes:
> If the jobs command is on the left hand side of a pipeline, the shell has
> to fork, and the jobs builtin runs in the forked process.  This process
> is not in control of any jobs, so the jobs command has nothing to report.

Now the question is:  why "on the left hand side" rather the other ?
Zsh isn't particularly lean and mean, os mayb eit makes sense to offer the
choice so that "jobs | something" can work (and so that we can choose which
process' exit status will be used for the whole pipe's exit status ?


	Stefan

Re: jobs command and pipes

[Zefram]

Stefan Monnier wrote:
>Now the question is:  why "on the left hand side" rather the other ?
>Zsh isn't particularly lean and mean, os mayb eit makes sense to offer the
>choice so that "jobs | something" can work (and so that we can choose which
>process' exit status will be used for the whole pipe's exit status ?

We almost have that already.  "jobs >>(tr a-z A-Z)" works, except that
it doesn't wait for the tr to terminate.  Perhaps that should be changed.

-zefram

Re: jobs command and pipes

[Dan Nelson]

In the last episode (Oct 30), Zefram said:
> Stefan Monnier wrote:
> >Now the question is:  why "on the left hand side" rather the other ?
> >Zsh isn't particularly lean and mean, os mayb eit makes sense to
> >offer the choice so that "jobs | something" can work (and so that we
> >can choose which process' exit status will be used for the whole
> >pipe's exit status ?
> 
> We almost have that already.  "jobs >>(tr a-z A-Z)" works, except
> that it doesn't wait for the tr to terminate.  Perhaps that should be
> changed.

If they're treated like background jobs, should "wait" wait for them to
finish?  Should "jobs" display them?  I vote for treating them like
pipes.

	-Dan Nelson
	dnelson@emsphone.com