[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash errexit shell option does not work in some cases.

From: Chet Ramey
Subject: Re: bash errexit shell option does not work in some cases.
Date: Mon, 8 Jun 2020 10:02:40 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

On 6/8/20 7:24 AM, Greg Wooledge wrote:
> On Mon, Jun 01, 2020 at 05:28:20PM +0700, Robert Elz wrote:
>> in this case:
>>   | You're merely the latest person to discover that this applies to you:
>>   | http://mywiki.wooledge.org/BashFAQ/105
>> doesn't really apply - the cases reported are simply bugs in bash,
>> a shell implementing -e correctly should exit as it was expected to.
> The specification of set -e is not fixed.  It keeps changing.  Bash
> implements a version of set -e that was specified at some point in
> the past, which included the phrase "simple command".  So, the rules
> that apply to compound commands and the rules that apply to simple
> commands are not the same.

This explanation is out of date. It's true that back as recently as
2008, POSIX specified that `set -e' worked only if a simple command
failed. Bash implemented that spec, which was incompatible with other
(and historical) shell implementations.
> A more recent POSIX specification has changed the wording, and therefore
> bash's implementation is out of date.  A future version of bash will
> conform to the new wording, which means it will (once again) break
> backward compatibility with older versions of bash (and also with any
> other shells that still implement the older specification).

We hashed out the problems with `set -e' starting back in 2009, and the
standard changed to match historical behavior. This meant that things like
pipelines, (command) subshells, and so on failing would cause the shell to
exit when errexit was enabled. I changed bash to match it starting with
version 4.0, which was followed by much gnashing of teeth and rending of
garments. I'm sure you recall.

No one is arguing that the standard did not change here. In this case,
there was a defect report, (extensive) discussion, an interpretation, and
the standard finally channged in 2013.

> Simply waving this off as a "bug in bash" is quite unfair.

These two cases are, in fact, bugs in bash. They are remnants from the
period when `set -e' only affected simple commands, true, but they are
bugs now nonetheless.

> This is part of the set -e nightmare, which is what we keep trying to
> get you (and everyone else) to understand.

Most of the issue with `set -e' is folks not understanding when it's
not in effect.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]