From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10475 invoked by alias); 17 Sep 2010 14:41:57 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28267 Received: (qmail 15654 invoked from network); 17 Sep 2010 14:41:55 -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: <100917074136.ZM31402@torch.brasslantern.com> Date: Fri, 17 Sep 2010 07:41:36 -0700 In-reply-to: <20100917094610.390f120f@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: PATCH: coprocess descriptor and error messages" (Sep 17, 9:46am) References: <100916220444.ZM30547@torch.brasslantern.com> <20100917094610.390f120f@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: PATCH: coprocess descriptor and error messages MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 17, 9:46am, Peter Stephenson wrote: } } The question is whether it's useful to be able to test whether the } coprocess is open at the same time as attempting to read or write. Is there another obvious way to test whether the coprocess is open? Aside: Should an interactive shell ever exit on SIGPIPE? Or maybe a better question is, should a print to the coprocess ever cause an un-trapped SIGPIPE? schaefer[713] Src/zsh -f torch% coproc repeat 8 read -E [1] 31339 torch% repeat 10 { print -p; read -p } schaefer[714] echo $? 141 } If so, doing it silently is reasonable. Otherwise it might be less } mysterious to print "coprocess not open", or something like that, } in both cases. In looking further, the coprocess descriptor is reset to -1 only (and immediately) by "read -p" detecting EOF on the coprocess output. So in the "read" case, the invalid descriptor has always served as an EOF flag. What should happen if the parent attempts to read after an EOF has been seen? I would tend to think it should just get EOF again, not produce a diagnostic, which is the current behavior. However, ksh (at least pdksh) disagrees with me: $ print -p ksh: print: -p: no coprocess $ read |& [1] 31399 $ print -p $ print -p ksh: print: -p: no coprocess [1] + Done read $ read -p $ read -p ksh: read: -p: no coprocess $ print -p ksh: print: -p: no coprocess $ Note, however, that it does NOT exit with SIGPIPE on "print -p".