From: Martijn Dekker <martijn@inlv.org>
To: DASH shell mailing list <dash@vger.kernel.org>,
busybox <busybox@busybox.net>,
Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org>,
Robert Elz <kre@munnari.OZ.AU>, Jilles Tjoelker <jilles@stack.nl>,
Harald van Dijk <harald@gigawatt.nl>
Subject: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Date: Thu, 6 Feb 2020 16:12:06 +0000 [thread overview]
Message-ID: <10e3756b-5e8f-ba00-df0d-b36c93fa2281@inlv.org> (raw)
This is probably the strangest bug (or maybe pair of bugs) I've run into
in nearly five years of breaking shells by developing modernish.
I've traced it to an interaction between bash >= 4.2 (i.e.: bash with
shopt -s lastpipe) and variants of the Almquist shell, at least: dash,
gwsh, Busybox ash, FreeBSD sh, and NetBSD 9.0rc2 sh.
Symptom: if 'return' is invoked on bash in the last element of a pipe
executed in the main shell environment, then if you subsequently 'exec'
an Almquist shell variant so that it has the same PID, its 'wait'
builtin breaks.
I can consistently reproduce this on Linux, macOS, FreeBSD, NetBSD
9.0rc2, OpenBSD, and Solaris.
To reproduce this, you need bash >= 4.2, some Almquist shell variant,
and these two test scripts:
---begin test.bash---
fn() {
: | return
}
shopt -s lastpipe || exit
fn
exec "${1:-dash}" test.ash
---end test.bash---
---begin test.ash---
echo '*ash-begin'
: &
echo '*ash-middle'
wait "$!"
echo '*ash-end'
---end test.ash---
When executing test.bash with dash, gwsh, Busybox ash, or FreeBSD sh,
then test.ash simply waits forever on executing 'wait "$!"'.
$ bash test.bash <some-almquist-shell>
*ash-begin
*ash-middle
(nothing until ^C)
NetBSD sh behaves differently. NetBSD 8.1 sh (as installed on sdf.org
and sdf-eu.org) seem to act completely normally, but NetBSD 9.0rc2 sh
(on my VirtualBox test VM) segfaults. Output on NetBSD 9.0rc2:
$ bash test.bash /bin/sh
*ash-begin
*ash-middle
[1] Segmentation fault bash test.bash sh
I don't know if the different NetBSD sh behaviour is because the older
NetBSD sh doesn't have the bug, or because some factor on the sdf*.org
systems causes it to not be triggered.
To me, this smells like the use of some uninitialised value on various
Almquist shells. Tracing that is beyond my expertise though.
Whether this also represents a bug in bash or not, I can't say. But no
other shells trigger this that I've found, not even ksh93 and zsh which
also execute the last element of a pipe in the main shell environment.
- Martijn
--
modernish -- harness the shell
https://github.com/modernish/modernish
next reply other threads:[~2020-02-06 16:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 16:12 Martijn Dekker [this message]
2020-02-06 19:29 ` Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait' Harald van Dijk
2020-02-07 11:19 ` AW: " Walter Harms
2020-02-07 14:33 ` Martijn Dekker
2020-02-07 16:16 ` Chet Ramey
2020-02-06 20:43 ` Robert Elz
2020-02-07 2:41 ` Robert Elz
2020-02-08 18:39 ` Harald van Dijk
2020-02-09 19:03 ` Jilles Tjoelker
2020-02-18 16:46 ` Denys Vlasenko
2020-02-18 21:59 ` Harald van Dijk
2020-02-18 18:17 ` Robert Elz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10e3756b-5e8f-ba00-df0d-b36c93fa2281@inlv.org \
--to=martijn@inlv.org \
--cc=bug-bash@gnu.org \
--cc=busybox@busybox.net \
--cc=dash@vger.kernel.org \
--cc=harald@gigawatt.nl \
--cc=jilles@stack.nl \
--cc=kre@munnari.OZ.AU \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).