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.
next prev parent 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).