Re: process substitution error handling

From	Greg Wooledge <wooledg@eeg.ccf.org>
Newsgroups	gnu.bash.bug
Subject	Re: process substitution error handling
Date	2020-08-06 08:24 -0400
Message-ID	<mailman.983.1596716690.2739.bug-bash@gnu.org> (permalink)
References	(1 earlier) <7496b183-2db3-6c03-6074-928adcd08f45@case.edu> <CAHmME9pzOY_0EJ69y9wt6r-Jh3frZpV8XdFC6zG5EOkZ99h-1A@mail.gmail.com> <CAH7i3LorhQnvpd0YvTcHsuHM4=v6kTQ+Z8Yf+L43AT1V3zKOFg@mail.gmail.com> <CAHmME9pUd51YvaRWD6az8XgJ=EFw+v+t6xdkBOUx=jqKnH1kbw@mail.gmail.com> <20200806122418.GW22833@eeg.ccf.org>

Show all headers | View raw

On Thu, Aug 06, 2020 at 02:14:07PM +0200, Jason A. Donenfeld wrote:
> On Thu, Aug 6, 2020 at 1:15 PM Oğuz <oguzismailuysal@gmail.com> wrote:
> >     set -e o substfail
> >     : <(sleep 10; exit 1)
> >     foo
> >
> > Say that `foo' is a command that takes longer than ten seconds to complete, how would you expect the shell to behave here? Should it interrupt `foo' or wait for its termination and exit then? Or do something else?
> 
> It's likely simpler to check after foo, since bash can just ask "are
> any of the process substitution processes that I was wait(2)ing on in
> exited state with non zero return?", which just involves looking in a
> little list titled exited_with_error_process_subst for being non-null.

So, in a script like this:

set -e -o failevenharder
: <(sleep 1; false)
cmd1
cmd2
cmd3
cmd4

They're asking that the script abort at some unpredictable point during
the sequence of commands cmd1, cmd2, cmd3, cmd4 whenever the process
substitution happens to terminate?

I'm almost tempted to get behind that just to help the set -e users
reach the point of terminal absurdity even faster.  The wreckage should
be hilarious.

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: process substitution error handling Greg Wooledge <wooledg@eeg.ccf.org> - 2020-08-06 08:24 -0400

csiph-web