From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16566 invoked from network); 30 Jun 2004 07:10:23 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.85) by ns1.primenet.com.au with SMTP; 30 Jun 2004 07:10:23 -0000 Received: (qmail 5034 invoked from network); 30 Jun 2004 08:21:17 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 30 Jun 2004 08:21:17 -0000 Received: (qmail 20700 invoked by alias); 30 Jun 2004 07:09:41 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7624 Received: (qmail 20690 invoked from network); 30 Jun 2004 07:09:40 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.85) by sunsite.dk with SMTP; 30 Jun 2004 07:09:40 -0000 Received: (qmail 3981 invoked from network); 30 Jun 2004 08:20:47 -0000 Received: from vinc17.net1.nerim.net (HELO ay.vinc17.org) (62.4.18.82) by a.mx.sunsite.dk with SMTP; 30 Jun 2004 08:20:37 -0000 Received: from lefevre by ay.vinc17.org with local (Exim 4.32) id 1BfZDK-0001rM-TW; Wed, 30 Jun 2004 09:09:02 +0200 Date: Wed, 30 Jun 2004 09:09:02 +0200 From: Vincent Lefevre To: zsh-users@sunsite.dk Subject: Re: coloring STDERR to terminal Message-ID: <20040630070902.GO2033@ay.vinc17.org> Mail-Followup-To: zsh-users@sunsite.dk References: <20040627190433.Q27888@willy_wonka> <20040629160826.GL2033@ay.vinc17.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: http://www.vinc17.org/mutt/ User-Agent: Mutt/1.5.6i Sender: Vincent Lefevre 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 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, 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. Thanks. > 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). I don't understand how this can happen. Otherwise this would mean that bytes from stderr could be discarded, which would also be very bad. Also, in the coprocess (while read line; ...), the colored data will be output only after a \n. However, one generally wants stderr to be output immediately (contrary to stdout), i.e. unbuffered instead of line buffered. I assume that -k 1 would fix that, but it would be inefficient. One could probably use "read -t -k 1" in a loop until it fails or return a \n. 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? -- Vincent Lefèvre - Web: 100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17, Championnat International des Jeux Mathématiques et Logiques, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA