From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13229 invoked by alias); 14 Oct 2013 15:09:05 -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: 18027 Received: (qmail 11981 invoked from network); 14 Oct 2013 15:08:50 -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 autolearn=ham version=3.3.2 Date: Mon, 14 Oct 2013 17:08:45 +0200 From: Vincent Lefevre To: zsh-users@zsh.org Subject: Re: process substitution bug with set -e? Message-ID: <20131014150845.GB31070@ypig.lip.ens-lyon.fr> Mail-Followup-To: zsh-users@zsh.org References: <20131014124126.GA31070@ypig.lip.ens-lyon.fr> <20131014144838.6ec034dd@pwslap01u.europe.root.pri> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20131014144838.6ec034dd@pwslap01u.europe.root.pri> X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.21-6305-vl-r59709 (2013-04-16) On 2013-10-14 14:48:38 +0100, Peter Stephenson wrote: > On Mon, 14 Oct 2013 14:41:27 +0200 > Vincent Lefevre wrote: > > #!/usr/bin/env zsh > > set -e > > { /bin/cp } 2>>(sleep 1; cat -n) > > > > Due to /bin/cp failure and the "set -e", the parent shell exits > > immediately, without waiting for the extra processes: > > > > ypig% ./zsh-procsubst > > ypig% 1 /bin/cp: missing file operand > > 2 Try '/bin/cp --help' for more information. > > > > (tested under Debian/unstable). > > > > Shouldn't the parent shell wait in this case? > > I may be thinking too naively here, but... > > It's not clear to me this is wrong, anyway (apart from the lack of > documentation). You're in a non-interactive shell with no job control > (it's possible to mix job control with ERR_EXIT although it seems rather > unnatural). So the shell has no way cleanly to kill jobs associated > with it. I don't want them to be killed, on the contrary. In my real script, the 2>>(...) is used to filter out informative messages and keep real error messages. Killing this process would mean that error messages would no longer be visible. > So it would have to wait until the sleep has finished (or any > other process, however long they took), and it doesn't necessarily know > they're going to exit --- which would be a bug in the script, but if > you've got ERR_EXIT set you probably want to avoid tickling script bugs > when that's in operation. I think it could be made to wait, but > there's a reasonable argument that as it's already detected the failure > and you've asked it to exit on failure it should just do that. > > I certainly don't claim this is a definitive answer. I can see that it has the same behavior as, for instance: { echo foo; exit } >>(sleep 1; cat -n) Again, one may wonder whether the shell should exit immediately. Is this clearly documented somewhere? I think this is the same problem, and the precise behavior should be documented. If the expected behavior is to exit immediately with "exit" or due to a non-zero exit status with "set -e", then there should be a way to behave as if the closing } were reached (instead of exiting immediately). With EXIT and ZERR traps? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)