Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16701
| From | "Jason A. Donenfeld" <Jason@zx2c4.com> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | process substitution error handling |
| Date | 2020-08-06 12:05 +0200 |
| Message-ID | <mailman.973.1596708367.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> |
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.
Chet - thoughts?
It'd certainly make a lot of my scripts more reliable.
Jason
Back to gnu.bash.bug | Previous | Next | Find similar
process substitution error handling "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-08-06 12:05 +0200
csiph-web