From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18299 invoked by alias); 9 Sep 2012 19:18:52 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 17243 Received: (qmail 29160 invoked from network); 9 Sep 2012 19:18:41 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120909121802.ZM17393@torch.brasslantern.com> Date: Sun, 09 Sep 2012 12:18:02 -0700 In-reply-to: <20120901115937.GC1777@localhost.localdomain> Comments: In reply to Han Pingtian "Re: Is it possible to capture stdout and stderr to separate variables in Zsh?" (Sep 1, 7:59pm) References: <1331054185.27052.19.camel@air.fifi.org> <120306230111.ZM11639@torch.brasslantern.com> <20120901115937.GC1777@localhost.localdomain> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Han Pingtian , zsh-users@zsh.org Subject: Re: Is it possible to capture stdout and stderr to separate variables in Zsh? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 1, 7:59pm, Han Pingtian wrote: } } I'm using zsh 5.0, but looks like still cannot close the prior coproc } with "coproc exit": } } % coproc while read line;do print -r -- "$line:u";done This is a bug/misfeature that I think I've mentioned before (possibly only on zsh-workers) which affects built-in commands including loop constructs. The trouble is that zsh opens the coproc descriptors in the parent shell (as it must) and marks them close-on-exec. It then forks for the actual coprocess job and dups the coproc descriptors to the job's stdin and stdout. Then the bug happens: Because the coprocess is a built-in, there is no exec, so the original coproc descriptors are never closed. This leaves the coprocess "talking to itself": zsh 17133 schaefer 0r FIFO 0,7 2256774 pipe zsh 17133 schaefer 1w FIFO 0,7 2256773 pipe zsh 17133 schaefer 2u CHR 136,2 4 /dev/pts/2 zsh 17133 schaefer 10u CHR 136,2 4 /dev/pts/2 zsh 17133 schaefer 11r FIFO 0,7 2256773 pipe zsh 17133 schaefer 14w FIFO 0,7 2256774 pipe Note that 14w is connected to 0r and 11r is connected to 1w, all in the same process. IIRC exactly the same thing happens in at least some revisions of ksh if you use a built-in construct as a coproc. The workaround for now is to close the coproc inside the coproc: % coproc { coproc exit; while read line;do print -r -- "$line:u";done }