Re: process substitution bug with set -e?

[Vincent Lefevre <vincent@vinc17.net>]

On 2013-10-14 14:48:38 +0100, Peter Stephenson wrote:
> On Mon, 14 Oct 2013 14:41:27 +0200
> Vincent Lefevre <vincent@vinc17.net> 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 <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)