Re: process substitution error handling

From	"Jason A. Donenfeld" <Jason@zx2c4.com>
Newsgroups	gnu.bash.bug
Subject	Re: process substitution error handling
Date	2020-08-06 14:29 +0200
Message-ID	<mailman.985.1596716960.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> <CAHmME9qCvKeY=OsnaRPyhQdAD87f0t1+OCY-m00G7n=fRMKxEA@mail.gmail.com>

Show all headers | View raw

On Thu, Aug 6, 2020 at 2:14 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Thu, Aug 6, 2020 at 1:15 PM Oğuz <oguzismailuysal@gmail.com> wrote:
> >
> >
> >
> > 6 Ağustos 2020 Perşembe tarihinde Jason A. Donenfeld <Jason@zx2c4.com> yazdı:
> >>
> >> Hi,
> >>
> >> It may be a surprise to some that this code here winds up printing
> >> "done", always:
> >>
> >> $ cat a.bash
> >> set -e -o pipefail
> >> while read -r line; do
> >>        echo "$line"
> >> done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
> >> sleep 1
> >> echo done
> >>
> >> $ bash a.bash
> >> 1
> >> 2
> >> done
> >>
> >> The reason for this is that process substitution right now does not
> >> propagate errors. It's sort of possible to almost make this better
> >> with `|| kill $$` or some variant, and trap handlers, but that's very
> >> clunky and fraught with its own problems.
> >>
> >> Therefore, I propose a `set -o substfail` option for the upcoming bash
> >> 5.1, which would cause process substitution to propagate its errors
> >> upwards, even if done asynchronously.
> >>
> >
> >     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.
>
> A more sophisticated implementation could do that asynchronously with
> signals and SIGCHLD. In that model, if bash gets sigchld from a
> process that exits with failure, it then exits inside the signal
> handler there. This actually wouldn't be too hard to do either.

Actually, it looks like all the infrastructure for this latter
approach is already there.

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

Thread

Re: process substitution error handling "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-08-06 14:29 +0200

csiph-web