Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16702

Re: process substitution error handling

From Oğuz <oguzismailuysal@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: process substitution error handling
Date 2020-08-06 14:15 +0300
Message-ID <mailman.980.1596712550.2739.bug-bash@gnu.org> (permalink)
References <20200420051508.GA2359844@zx2c4.com> <7496b183-2db3-6c03-6074-928adcd08f45@case.edu> <CAHmME9pzOY_0EJ69y9wt6r-Jh3frZpV8XdFC6zG5EOkZ99h-1A@mail.gmail.com> <CAH7i3LorhQnvpd0YvTcHsuHM4=v6kTQ+Z8Yf+L43AT1V3zKOFg@mail.gmail.com>

Show all headers | View raw


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?


> Chet - thoughts?
>
> It'd certainly make a lot of my scripts more reliable.
>
> Jason
>
>

-- 
Oğuz

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


Thread

Re: process substitution error handling Oğuz <oguzismailuysal@gmail.com> - 2020-08-06 14:15 +0300

csiph-web