From: Harald van Dijk <harald@gigawatt.nl>
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Robert Elz <kre@munnari.oz.au>, Martijn Dekker <martijn@inlv.org>,
busybox <busybox@busybox.net>,
DASH shell mailing list <dash@vger.kernel.org>,
Jilles Tjoelker <jilles@stack.nl>,
Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org>
Subject: Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Date: Tue, 18 Feb 2020 21:59:37 +0000 [thread overview]
Message-ID: <f2a928d6-4feb-d123-23b4-17c8edfeda2f@gigawatt.nl> (raw)
In-Reply-To: <CAK1hOcO_S_T=5SWJ0jpZWxDYwdUFqJisw_nC+JysnQvZ6XUuKw@mail.gmail.com>
On 18/02/2020 16:46, Denys Vlasenko wrote:
> On Sat, Feb 8, 2020 at 7:41 PM Harald van Dijk <harald@gigawatt.nl> wrote:
>> If NetBSD sh
>> manages to avoid this pattern, and assuming NetBSD sh is not still
>> susceptible to one of those race conditions
>
> Please let us know what you discovered.
Okay, please take a look. I hope I managed to avoid race conditions in
the test shell script.
test1.sh:
i=1
while test "$i" -lt 100000
do
printf "%d\r" "$i"
"$@" test2.sh
i=$((i + 1))
done
test2.sh
trap 'kill $!; exit 0' TERM
{ kill $$; exec sleep 1000; } &
wait $!
To run:
sh test1.sh $shell
For instance:
sh test1.sh busybox ash
test1.sh will repeatedly run test2.sh and increment and print a counter
variable to display progress.
test2.sh will immediately exit, in a complicated way, if all goes well.
It may sleep for 1000s or fail to clean up its background process if
something goes wrong.
On my system, I see:
bash 5.0.11 - sleeps after a while
bosh 2019-11-11 - sleeps after a while
busybox 1.31.1 ash - ok
dash 0.5.10.2 - ok
dash (current) - sleeps immediately
fbsh 12.1 - ok *
gwsh (current) - leaves subprocesses
ksh 93v - sleeps after a while
ksh 2020.0.0 - sleeps after a while
mksh 57 - sleeps after a while
nbsh (current) - sleeps after a while *
pdksh 5.2.14 - leaves subprocesses + sleeps after a while
posh 0.13.1 - ok
yash - ok
zsh - sleeps after a while
* Because of the way I was running FreeBSD sh and NetBSD sh on qemu, I
could not easily check what happens to the subprocesses.
I think that confirms that NetBSD sh does have a problem with a race
condition, but that many shells have that same problem. It also tells me
that there is another different problem in my shell that I should look at.
Cheers,
Harald van Dijk
next prev parent reply other threads:[~2020-02-18 22:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 16:12 Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait' Martijn Dekker
2020-02-06 19:29 ` 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 [this message]
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=f2a928d6-4feb-d123-23b4-17c8edfeda2f@gigawatt.nl \
--to=harald@gigawatt.nl \
--cc=bug-bash@gnu.org \
--cc=busybox@busybox.net \
--cc=dash@vger.kernel.org \
--cc=jilles@stack.nl \
--cc=kre@munnari.oz.au \
--cc=martijn@inlv.org \
--cc=vda.linux@googlemail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.