From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19027 invoked from network); 29 Jun 2004 17:15:11 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.85) by ns1.primenet.com.au with SMTP; 29 Jun 2004 17:15:10 -0000 Received: (qmail 358 invoked from network); 29 Jun 2004 18:25:37 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 29 Jun 2004 18:25:37 -0000 Received: (qmail 12247 invoked by alias); 29 Jun 2004 17:14:26 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7621 Received: (qmail 12237 invoked from network); 29 Jun 2004 17:14:26 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.85) by sunsite.dk with SMTP; 29 Jun 2004 17:14:26 -0000 Received: (qmail 31882 invoked from network); 29 Jun 2004 18:25:09 -0000 Received: from unknown (HELO moonbase.zanshin.com) (@167.160.213.139) by a.mx.sunsite.dk with SMTP; 29 Jun 2004 18:24:59 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.12.11/8.12.11) with ESMTP id i5THEDYD016334 for ; Tue, 29 Jun 2004 10:14:13 -0700 Date: Tue, 29 Jun 2004 10:14:13 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-users@sunsite.dk To: zsh-users@sunsite.dk Subject: Re: coloring STDERR to terminal In-Reply-To: <20040629160826.GL2033@ay.vinc17.org> Message-ID: References: <20040627190433.Q27888@willy_wonka> <20040629160826.GL2033@ay.vinc17.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 On Tue, 29 Jun 2004, Vincent Lefevre wrote: > On 2004-06-29 08:43:50 -0700, Bart Schaefer wrote: > > coproc while read line; print '\e[91m'${(q)line}'\e[0m' > /dev/tty > > exec 2>&p > > It doesn't work very well. Humph. Depends on your definition of "very well." Everything sent to the standard error is printed in red, isn't it? > Normally, if I do a Ctrl-d when there are > running jobs, I get: > > greux:~> > zsh: you have running jobs. > greux:~> Which is exactly what I get even with the coproc, so there's something system-specific going on here (race condition resolved differently by the kernel process scheduler, perhaps). > With the coprocess, I get: > > greux:~> > greux:~> zsh: you have running jobs. If you want something fancier, have the coproc print a single byte to its stdout every time around the read loop, and put something like while read -t -p -k 1; do :; done in the precmd() function to force the main shell to synchronize with the coproc before it prints the prompt. 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 (which is the trouble with filtering the output of programs that don't expect to have their output filtered, but that wasn't the question).