From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13030 invoked from network); 2 Jul 2004 00:12:08 -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 00:12:08 -0000 Received: (qmail 25076 invoked from network); 2 Jul 2004 01:23:57 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 2 Jul 2004 01:23:57 -0000 Received: (qmail 25727 invoked by alias); 2 Jul 2004 00:11:24 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7656 Received: (qmail 25717 invoked from network); 2 Jul 2004 00:11:23 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.85) by sunsite.dk with SMTP; 2 Jul 2004 00:11:23 -0000 Received: (qmail 24255 invoked from network); 2 Jul 2004 01:23:38 -0000 Received: from unknown (HELO moonbase.zanshin.com) (@167.160.213.139) by a.mx.sunsite.dk with SMTP; 2 Jul 2004 01:23:25 -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 i620B8IC026313 for ; Thu, 1 Jul 2004 17:11:08 -0700 Date: Thu, 1 Jul 2004 17:11:08 -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: <20040701181459.GF2033@ay.vinc17.org> Message-ID: 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=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 Thu, 1 Jul 2004, Vincent Lefevre wrote: > I don't understand why it will block. The line you gave was: > > while read -t -p -k 1; do :; done Ah. You're right; I had only a half-formed thought, there. I originally wrote (before sending my message, i.e. during the editing process) "read -p -k 1" (no loop), implying always read one byte from the coprocess. But in re-reading I realized that blocks forever when there is no stderr for the coproc to colorize. So I changed it to the "while" loop, which would do nothing if the coprocess produced no output, and read the byte otherwise. But I failed to notice that this also means it does nothing if the coproc has not written the byte *yet*, which is what you were pointing out. 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.