From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22722 invoked by alias); 16 Mar 2011 14:58:02 -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: 15878 Received: (qmail 2758 invoked from network); 16 Mar 2011 14:57:51 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110316075735.ZM19183@torch.brasslantern.com> Date: Wed, 16 Mar 2011 07:57:35 -0700 In-reply-to: Comments: In reply to Rory Mulvaney "coproc problem when input closed but output open" (Mar 15, 2:04pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: coproc problem when input closed but output open MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Mar 15, 2:04pm, Rory Mulvaney wrote: } } Now I'm having trouble with another example, where the coproc doesn't } return without killing it. Maybe the problem has something to do with the } output file descriptor of the coproc still being open. But shouldn't the } coproc finish writing its output and exit? You still have "cat <&6 &" running in the background. That has a copy of the coproc's stdin (fd5) open, because it inherited all the descriptors of the parent shell and fd5 is not specially closed the way the "p" descriptor is. You can use cat <&6 5>&- & to be sure cat doesn't inherit fd5. It might be clearer if you restructure the code to be: coproc wcFunc wcf=$! # copy output of coproc to stdout cat <&p & # copy the write and read fd's for the coproc exec 5>&p 6<&p exec 6<&- # start another null coproc to get a new target for the p fd coproc exit Then you don't need to fiddle with fd5 when starting the cat.