From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26617 invoked from network); 2 Jul 2004 12:44:28 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.85) by ns1.primenet.com.au with SMTP; 2 Jul 2004 12:44:28 -0000 Received: (qmail 7061 invoked from network); 2 Jul 2004 13:56:41 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 2 Jul 2004 13:56:41 -0000 Received: (qmail 13348 invoked by alias); 2 Jul 2004 12:43:40 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7658 Received: (qmail 13337 invoked from network); 2 Jul 2004 12:43:40 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.85) by sunsite.dk with SMTP; 2 Jul 2004 12:43:40 -0000 Received: (qmail 6169 invoked from network); 2 Jul 2004 13:56:16 -0000 Received: from vinc17.net1.nerim.net (HELO ay.vinc17.org) (62.4.18.82) by a.mx.sunsite.dk with SMTP; 2 Jul 2004 13:56:02 -0000 Received: from lefevre by ay.vinc17.org with local (Exim 4.32) id 1BgNNb-0006D7-EU; Fri, 02 Jul 2004 14:42:59 +0200 Date: Fri, 2 Jul 2004 14:42:59 +0200 From: Vincent Lefevre To: zsh-users@sunsite.dk Subject: Re: coloring STDERR to terminal Message-ID: <20040702124259.GS2033@ay.vinc17.org> Mail-Followup-To: zsh-users@sunsite.dk References: <20040627190433.Q27888@willy_wonka> <20040629160826.GL2033@ay.vinc17.org> <20040630070902.GO2033@ay.vinc17.org> <20040630114341.GR2033@ay.vinc17.org> <20040701181459.GF2033@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-07-01 17:11:08 -0700, Bart Schaefer wrote: > So I'm forced to conclude that there really is no way to avoid the > race condition that you originally complained about; my first > solution is as good as it gets. You might get close if you used > "read -t 1 ..." to make the parent shell sleep so the kernel can > schedule the coprocess first, but then you'd have an annoying > 1-second delay on almost every prompt. Sorry. I have a better solution. stderr is redirected with exec 2>>(while read line; do print '\e[91m'${(q)line}'\e[0m' > /dev/tty; done &) as you suggested (this avoids the coprocess in the jobs table). Now, in precmd(), adding the following line solves the problem: sleep 0 Of course, this won't completely avoid the race condition, but it improves things in pratice. I assume that this forces the scheduler to switch to another process, and in practice, the coprocess is scheduled before precmd() is resumed. -- 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