Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: why does "jobs | wc" not work?
- X-seq: zsh-users 5532
- From: Dominik Vogt <dominik.vogt@xxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: why does "jobs | wc" not work?
- Date: Tue, 26 Nov 2002 13:48:14 +0100
- In-reply-to: <14578.1038312496@xxxxxxx>
- Mail-followup-to: zsh-users@xxxxxxxxxx
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20021126114222.GG1937@xxxxxx> <14578.1038312496@xxxxxxx>
- Reply-to: dominik.vogt@xxxxxx
On Tue, Nov 26, 2002 at 12:08:16PM +0000, Peter Stephenson wrote:
> Dominik Vogt wrote:
> > > In zsh
> > >
> > > jobs | anything
> > >
> > > causes the shell to fork for the left hand side of the pipeline.
> >
> > Um, why must builtin commands run in a subshell? I would have
> > naively thought commands like "echo something | ..." would just
> > run in the current shell. Spawning a subshell sounds a bit
> > inefficient.
>
> That's how all pipes work in all shells and scripting languages in all
> variants of UNIX: one process feeds its output to another process, so
> one side of the pipe has to be forked as a separate process. The only
> question is which bits are forked off.
Okay, understood.
>From a user's point of view I think it would be better to fork the
right hand side of the pipe. This way, the left hand side always
generates the same output, regardless of the context in which it
is used. Of course this is not better per se, but only because
more often the output is generated by the left side of the pipe.
Not that I want to talk you into changing anything. In my eyes,
the real flaw lies in the design of the jobs command. Commands
printing information about the current shell should not rely on
design choices inherent to the shell.
> The only obvious alternative is the horrible method which used to be
> used in MSDOS: fake separate processes by switching between the two
> tasks; but we are certainly never going to have a task manager in the
> shell when we have a proper multiprocessor operating system to do the
> job more efficiently.
Nobody wants to go back to MSDOS days :-)
> > > In 4.1, we use the obvious workaround: remember that we're in a subshell
> > > of an interactive shell and keep a fossilized list of the jobs.
> >
> > Obvious, maybe, but it still sounds wrong in my ears.
>
> Just in case my explanation above hasn't made this remark obvious:
> wrong in what way?
In exporting private information of a shell to other shells.
> It's either that or no output at all.
Personally, I would just document that fact in the man page and
point the user to the right way to acquire this information.
Note: Due to the inherent design of zsh and some other shells,
the jobs command does not work on the left hand side of a pipe
(e.g. "jobs | grep zsh"). The same information can be acquired
from the job... parameters. See section <xyz> in the
zsh<foobar> man page for details.
Anyway, documenting such pitfalls right in the command
descriptions in the man page is a good idea.
Bye
Dominik ^_^ ^_^
Messages sorted by:
Reverse Date,
Date,
Thread,
Author