Zsh Mailing List Archive
Messages sorted by:
Re: coloring STDERR to terminal
- X-seq: zsh-users 7717
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: coloring STDERR to terminal
- Date: Tue, 20 Jul 2004 09:10:15 -0700 (PDT)
- In-reply-to: <20040720045514.V326@willy_wonka>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20040627190433.Q27888@willy_wonka> <Pine.LNX.4.60.0406280815130.19831@xxxxxxxxxxxxxxxxxx> <20040629160826.GL2033@xxxxxxxxxxxxx> <Pine.LNX.4.60.0406291002300.31134@xxxxxxxxxxxxxxxxxx> <20040630070902.GO2033@xxxxxxxxxxxxx> <Pine.LNX.4.60.0406300311020.5600@xxxxxxxxxxxxxxxxxx> <20040630114341.GR2033@xxxxxxxxxxxxx> <Pine.LNX.4.60.0406300906100.5600@xxxxxxxxxxxxxxxxxx> <20040701181459.GF2033@xxxxxxxxxxxxx> <Pine.LNX.4.60.0407011645450.16728@xxxxxxxxxxxxxxxxxx> <20040702124259.GS2033@xxxxxxxxxxxxx> <20040720045514.V326@willy_wonka>
- Reply-to: zsh-users@xxxxxxxxxx
On Tue, 20 Jul 2004, Atom 'Smasher' wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> as i suspected, there doesn't seem to be a really good way to do this...
> although there are several ways to ~almost~ do it well.
> that said, i'd like to request a feature for coloring STDERR.
Your first sentence is quite literally true, which makes your feature
request a little pointless. It doesn't matter by whom [*] the coloring is
done; all the problems so far discussed are still present, with the
possible exception of zsh being able to avoid printing a prompt in the
middle of the error output.
Even if you were to create a single process that could monitor both the
stdout and stderr of every command run by zsh, and properly merge those
streams so that the colors look right on the terminal, you can't avoid the
issue that the stdio library changes its internal buffering behavior when
the output file descriptors are not connected to TTY devices; so you'd
have to use pseudo-TTYs instead of simple pipes. Even that is still
subject to race conditions that can't be guaranteed to resolve the way
they would if the two streams were going directly to the same TTY.
On top of that, you need a scheme for dealing with interactive programs
(or anything that does screen redraws involving cursor movement) such as
text editors, that need their own direct and unmunged access to the actual
terminal device. You'd have to create some sort of registry for them,
like the "needsterminal" attribute in mailcap files, and deal with the
headache of keeping that up to date for every new progam.
The cumulative complexity of implementation is not worth the benefit.
[*] If the kernel drivers could do it between the process output and the
terminal display, you might get something close to what you want, but in
that case you're on the wrong mailing list.
> maybe a STDIN_COL and STDOUT_COL could also be handy?
You don't really mean "stdin color" you mean "the ZLE editor buffer is a
different color than the ZLE prompts." I hope. Otherwise you're asking
for another process between the terminal and the input of every command,
which process subsumes the role of the terminal driver in echoing back the
characters typed. There are programs that do this (run zsh in an emacs
buffer, for example) but they have their own set of quirks.
For the ZLE buffer, you can color that with some careful settings of the
various prompt variables.
Messages sorted by: