Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15485
| From | Webstrand <webstrand@gmail.com> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Bug when using pipefail and lastpipe together in bash-4.4 |
| Date | 2019-10-08 09:43 -0400 |
| Message-ID | <mailman.1368.1570545550.2651.bug-bash@gnu.org> (permalink) |
| References | <CACm1TQebG+cnYuxqFSU7uu29XczQdRiO_M1RW-ne3isZkwbwsg@mail.gmail.com> |
[Multipart message — attachments visible in raw view] - view raw
When running the following script under bash-4.4.0 to bash-4.4.23 it
seems to fail erroneously on read.
set -x
set -o pipefail
shopt -s lastpipe
main() {
# Any input piped into while such that the condition
# succeeds at least once.
echo "x" | while read; do
echo | read # anything piped to read
sleep 0 # any non-builtin
done
}
main || echo "main failed"
This produces the xtrace:
+ set -o pipefail
+ shopt -s lastpipe
+ main
+ read
+ echo x
+ read
+ echo
+ sleep 0
+ read
+ echo 'main failed'
main failed
Under bash-4.3 and bash-5.0 the script does not output "main failed",
as expected.
I'm not sure if this is a known bug. One user on IRC reported finding
the same issue on debian stretch, but another could not reproduce the
issue for bash-4.4.12.
I have bisected the history of the devel git branch and found that the commit:
85ec0778f9d778e1820fb8c0e3e996f2d1103b45 commit bash-20150417 snapshot
introduces the issue.
Applying the attached patch to a bash-4.4.23 source tree produces an
interpreter which does not output "main failed" when running the
aforementioned script.
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Bug when using pipefail and lastpipe together in bash-4.4 Webstrand <webstrand@gmail.com> - 2019-10-08 09:43 -0400
csiph-web