From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18189 invoked by alias); 14 Oct 2013 16:23:23 -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: 18028 Received: (qmail 12405 invoked from network); 14 Oct 2013 16:23:17 -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 From: Bart Schaefer Message-id: <131014092324.ZM494@torch.brasslantern.com> Date: Mon, 14 Oct 2013 09:23:24 -0700 In-reply-to: <20131014150845.GB31070@ypig.lip.ens-lyon.fr> Comments: In reply to Vincent Lefevre "Re: process substitution bug with set -e?" (Oct 14, 5:08pm) References: <20131014124126.GA31070@ypig.lip.ens-lyon.fr> <20131014144838.6ec034dd@pwslap01u.europe.root.pri> <20131014150845.GB31070@ypig.lip.ens-lyon.fr> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: process substitution bug with set -e? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 14, 5:08pm, Vincent Lefevre wrote: } Subject: Re: process substitution bug with set -e? } } 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: } > > } > > Shouldn't the parent shell wait in this case? } > } > 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). I tried the above with "setopt MONITOR" and that doesn't have any effect; ERR_EXIT always wins, and MONITOR isn't necessary if ERR_EXIT is not set, even if the shell is not interactive. By comparison, if that command is run with "zsh -c ..." instead of as a script, zsh *never* waits for >>(...), regardless of other setopts. This seems to be a side-effect of the exec optimization which decides that, because there are no further commands to execute after { /bin/cp }, the parent can simply start that up and disappear. That is, zsh -c '{ /bin/cp } 2>>(sleep 1; cat -n)' always exits as soon as /bin/cp exits, whereas zsh -c '{ /bin/cp } 2>>(sleep 1; cat -n) ; :' waits for "cat -n" so that it can execute ":" after it. (Interestingly, adding a TRAPZERR also induces -c to wait, I'm not sure why.) } > 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 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? In general exiting from the shell either kills or disowns all jobs. The example of >>(process) is sort of a magic special case; it has to be run asynchronously to be of any use, but "logically" it's part of the whole job that is redirected to it, so when there is more to happen after it zsh automatically does a "wait" for the implicitly backgrounded subshell. That doesn't override the general rule about exiting. Whether this is "clearly documented" ... Incidentally exiting also bails out of "always" constructs without executing the final block. } 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? AFAICT this "there should be a way" isn't reflected in any other shell. "TRAPEXIT() { wait }" almost works, but blocks the parent forever. (?)