From: Martijn Dekker <martijn@inlv.org>
To: Walter Harms <wharms@bfs.de>,
Harald van Dijk <harald@gigawatt.nl>,
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>
Subject: Re: AW: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Date: Fri, 7 Feb 2020 14:33:46 +0000 [thread overview]
Message-ID: <967b5a41-31b7-0ec1-fb04-62af1617a86b@inlv.org> (raw)
In-Reply-To: <cbe5644f6db94eb89e4088141c426f8a@bfs.de>
Op 07-02-20 om 12:19 schreef Walter Harms:
> IMHO is the bug on bash side. ash can assume to get an "healthy"
> environment from the caller. You can simply not fix everything that
> can possible go wrong.
That is a rather fallacious argument. Of course you cannot fix
*everything* that could possibly go wrong. You can certainly fix *this*
thing, though. I know, because every non-Almquist shell does it.
These days, no program can realistically assume a "healthy" environment.
Computers have become unimaginably complex machines, built on thousands
of interdependent abstraction layers, each as fallible as the humans
that designed and implemented them. So "unhealthy" environments happen
all the time, due to all sorts of unforeseen causes.
It's well past time to accept that the 1980s are behind us. In 2020,
systems have to be programmed robustly and defensively.
> Obviously it should not segfault but so far i understand it is bsd as
> that does, not busybox ash.
True. But instead, it simply gets stuck forever, with no message or
other indicator of what went wrong. How is that better?
(Going slightly off-topic below...)
Segfaulting is actually a good thing: it's one form of failing reliably.
And failing reliably is vastly better than what often happens instead,
especially in shell scripts: subtle breakage, which can take a lot of
detective work to trace, and in some cases can cause serious damage due
to the program functioning inconsistently and incorrectly (instead of
not at all).
Failing reliably is something the shell is ATROCIOUSLY bad at, and it's
one of the first things modernish aims to fix.
- Martijn
--
modernish -- harness the shell
https://github.com/modernish/modernish
next prev parent reply other threads:[~2020-02-07 14:34 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 [this message]
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=967b5a41-31b7-0ec1-fb04-62af1617a86b@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 \
--cc=wharms@bfs.de \
/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).