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: Wed, 30 Jun 2004 03:52:46 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.60.0406300311020.5600@toltec.zanshin.com> (raw)
In-Reply-To: <20040630070902.GO2033@ay.vinc17.org>

On Wed, 30 Jun 2004, Vincent Lefevre wrote:

> On 2004-06-29 10:14:13 -0700, Bart Schaefer wrote:
> > If you want something fancier, have the coproc print a single byte to 
> > its stdout every time around the read loop

To clarify, by this I mean to its original standard output, not to the 
redirected stdout which is going to /dev/tty (otherwise the parent zsh 
can't see it).  E.g. instead of

 coproc while read line; print '\e[91m'${(q)line}'\e[0m' > /dev/tty

You need

 coproc while read line; do
          print '\e[91m'${(q)line}'\e[0m' > /dev/tty
          print -n $'\0'
        done

>[...] 
> > However, if you produce more lines of output between commands than
> > there are bytes of space in the socket buffer you'll block the
> > coproc and potentially deadlock everything
> 
> I don't understand how this can happen.

The situation is thus: The parent zsh (Z) holds the write-end (W) of the 
standard input of coprocess (C), and the read end (R) of the standard 
output of the coprocess.  Within the coprocess, the first print command 
has its standard output redirected to the terminal (T), but the second is 
still writing on R.

Z passes a copy of W to new job (J) as its stderr, then waits for J.

C is thus reading from W and writing to both T and to R, but Z is not 
reading from R (because Z is waiting), so C can only execute as many loops 
as there are bytes in the buffer for R before C blocks.  If C blocks, it 
stops reading from W, which means that eventually the buffer for W will 
fill up and also block J.  Deadlock.

This happens even faster when Z and J are the same process (a built-in
command or shell function).  The whole thing operates much better if C
is independent of Z, and you live with the race condition that means you
may sometimes get a prompt in the middle of your error output.

Which is, in part, why I said whether it "doesn't work very well" depends 
on your definition of "very well."  It works as well as it can, given the
original premise.

Using "read -t" in C's while loop test doesn't help with this, because the 
gating factor is Z waiting on J.  If you put J in the background (so Z is 
not waiting on it), the gating factor becomes Z waiting on input from the 
terminal at the prompt, but that you can solve with a "zle -F" handler (in 
4.2.1 or later).

> Wouldn't it be fine to have a read option (e.g. -T) that does this, i.e. 
> read what is requested (i.e. until \n or num characters if -k is used) 
> or return as soon as nothing else is available?

See "sysread" (and "syswrite") in the zsh/system module.


  reply	other threads:[~2004-06-30 10:53 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 [this message]
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
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.60.0406300311020.5600@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).