Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Piping stderr (was Re: Two bug reports)
- X-seq: zsh-workers 16892
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxxxxx>
- Subject: Re: Piping stderr (was Re: Two bug reports)
- Date: Sun, 24 Mar 2002 19:02:07 +0000
- In-reply-to: <Pine.LNX.4.33L2.0203240032180.20227-100000@xxxxxxxxxxxxxxx>
- In-reply-to: <1016988453.3443.1.camel@xxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <Pine.LNX.4.33L2.0203240032180.20227-100000@xxxxxxxxxxxxxxx> <1016988453.3443.1.camel@xxxxxxxxxxxxxxxxxxxxx>
On Mar 24, 1:01am, Wayne Davison wrote:
} Subject: Re: Piping stderr (was Re: Two bug reports)
}
} On Sat, 23 Mar 2002, Bart Schaefer wrote:
} >
} > You mean, other than `2>>(...)'?
}
} (I had apparently neglected to find that syntax when I was searching
} the zsh man page.)
The man page could stand improvement in this area. Even though pipes are
not redirections, people tend to think of them that way, and it's very
confusing that >(...) and |& are not at least cross-referenced in the
same section as all the redirection operators. Even `|&' is buried in
the middle of a boring-looking paragraph in the Shell Grammar section,
and never metioned again.
} So, I suppose that Peter's reply to David Hughes could be ammended to
}
} /bin/sh -c 'echo out; echo err >&2' >/dev/null 2>>(cat)
}
} The bad thing about this idiom is that it doesn't wait for "cat" to
} finish before moving on.
That's a separate bug that I've been complaining about for a while. I
really think zsh should be tracking >(...) as a job and waiting for it
rather than treating it as if disowned. That would be a much cleaner
solution from the viewpoint of the shell language (though possibly a bit
messier internally) than would adding a new pipe syntax.
As I pointed out in a follow-up you can work around it by doing an extra
pipe:
/bin/sh -c 'echo out; echo err >&2' >/dev/null 2>>(cat) | cat
In fact (hand smacks forehead), just add braces:
{ /bin/sh -c 'echo out; echo err >&2' >/dev/null 2>>(cat) }
} > The problem being that in order to pipe "just stderr" you have
} > to dispose of stdout somehow.
}
} No, stdout doesn't need to be affected at all. If the user wants stdout
} to go somewhere other than the default, it can be redirected explicitly
} (as I did above).
Leaving stdout connected to the parent's stdout is still "disposing of"
stdout; it's equivalent to:
zsh% 3>&1 { { /bin/sh -c 'echo out; echo err >&2' >&3 } |& tr a-z A-Z }
out
ERR
(The placement of `3>&1' there is illustrative, it could just as easily
go after the last close brace.) You can always defeat multios by adding
braces.
--
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author