[Top][All Lists]

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

Re: process substitution error handling

From: Eli Schwartz
Subject: Re: process substitution error handling
Date: Thu, 6 Aug 2020 08:33:01 -0400

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 $?"

> 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.

Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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