From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 739 invoked from network); 30 Jun 2004 11:45:11 -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 11:45:11 -0000 Received: (qmail 29995 invoked from network); 30 Jun 2004 12:55:59 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 30 Jun 2004 12:55:59 -0000 Received: (qmail 5687 invoked by alias); 30 Jun 2004 11:44:21 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7628 Received: (qmail 5675 invoked from network); 30 Jun 2004 11:44:20 -0000 Received: from odin.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.85) by sunsite.dk with SMTP; 30 Jun 2004 11:44:20 -0000 Received: (qmail 28962 invoked from network); 30 Jun 2004 12:55:30 -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 12:55:23 -0000 Received: from lefevre by ay.vinc17.org with local (Exim 4.32) id 1BfdV7-0003IF-NK; Wed, 30 Jun 2004 13:43:41 +0200 Date: Wed, 30 Jun 2004 13:43:41 +0200 From: Vincent Lefevre To: zsh-users@sunsite.dk Subject: Re: coloring STDERR to terminal Message-ID: <20040630114341.GR2033@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> 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-30 03:52:46 -0700, Bart Schaefer wrote: > 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 [...] > 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. [...] Thanks for the explanation. But in fact, I didn't add the print -n $'\0' line, so there is no R problem in my case. So, is this line really useful? Also, when I quit zsh, the coprocess is not killed (the NO_HUP option is set, but a coprocess can be seen as a particular case). Is it a bug? And is it possible to hide the coprocess from the jobs table? -- 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