Re: process substitution error handling

On 06/08/2020 13:33, Eli Schwartz wrote:
> On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> > 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.
>
> Well, yes, it is an async command. But errexit has lots of other amusing
> traps, like
>
> $ echo $(false)
>
> > 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.
>
> Propagate the return value of async processes like this:
>
> wait $! || die "async command failed with return status $?"

You beat me to it. I was just about to suggest wait $! || exit. Indeed, 
I mentioned the same in a recent bug report against wireguard-tools.

> > It'd certainly make a lot of my scripts more reliable.
>
> The use of errexit is the focus of a long-running holy war. Detractors
> would point out a very lengthy list of reasons why it's conceptually
> broken by design. Some of those reasons are documented here (including
> process substitution): http://mywiki.wooledge.org/BashFAQ/105
>
> I recommend you do NOT claim this feature is a magic panacea that will
> make your scripts reliable; instead, just say you would find it useful.

I concur. The scripts I looked at tended heavily towards error handling 
at a distance and were already subject to one or two amusing errexit 
pitfalls.

--
Kerin Millar