[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: process substitution error handling

Subject: Re: process substitution error handling
Date: Thu, 6 Aug 2020 14:15:40 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.1.0

On 06/08/2020 13:33, Eli Schwartz wrote:
On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]