zsh-users
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-users@sunsite.dk
Subject: Re: coloring STDERR to terminal
Date: Tue, 20 Jul 2004 09:10:15 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.61.0407200805410.7638@toltec.zanshin.com> (raw)
In-Reply-To: <20040720045514.V326@willy_wonka>

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.


  reply	other threads:[~2004-07-20 16:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-27 23:22 Atom 'Smasher'
2004-06-28  0:06 ` ari
2004-06-28  0:36   ` Atom 'Smasher'
2004-06-29 15:43 ` Bart Schaefer
2004-06-29 16:08   ` Vincent Lefevre
2004-06-29 17:14     ` Bart Schaefer
2004-06-30  7:09       ` Vincent Lefevre
2004-06-30 10:52         ` Bart Schaefer
2004-06-30 11:43           ` Vincent Lefevre
2004-06-30 12:01             ` Vincent Lefevre
2004-06-30 16:56             ` Bart Schaefer
2004-07-01 18:14               ` Vincent Lefevre
2004-07-02  0:11                 ` Bart Schaefer
2004-07-02 12:42                   ` Vincent Lefevre
2004-07-02 21:32                     ` Bart Schaefer
2004-07-20  9:10                     ` Atom 'Smasher'
2004-07-20 16:10                       ` Bart Schaefer [this message]
2004-07-20 19:27                         ` Atom 'Smasher'
2004-07-20 21:15                           ` Bart Schaefer
2004-07-20 23:30                             ` Wayne Davison
2004-07-21  3:15                               ` Bart Schaefer
2004-07-21  6:23                                 ` Wayne Davison
2004-07-21  7:30                                   ` Bart Schaefer
2004-07-21 13:19                                   ` Vincent Lefevre
2004-07-30 11:50                     ` Andy Spiegl
2004-07-30 23:44                       ` Vincent Lefevre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0407200805410.7638@toltec.zanshin.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-users@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).