Re: why does errexit exist in its current utterly useless form?

[Chet Ramey]

On 12/15/12 11:54 AM, matei.david@gmail.com wrote:
> On Friday, December 14, 2012 6:23:41 PM UTC-5, Eric Blake wrote:
>> Short answer: historical compatibility.  'set -e' has been specified to
>> behave the way it did 30 years ago in one reference implementation, and
>> while you can argue till you are blue in the face that the reference
>> implementation is not intuitive, you have to at least appreciate that
>> having a standard means you are likely to get the same (non-intuitive)
>> behavior among several competing shell implementations that all strive
>> to conform to POSIX.
> 
> Thanks for the reply. I understand the benefits of a standard. In this case, 
> it seems to me that the problem we're talking about- stopping a script as 
> soon as a command returns an unexpected non-0 code- is a very basic feature 
> that many could benefit from, if implemented right. I'm trying to understand 
> whether or not fixing this problem requires changing the standard or not.

The behavior you want requires changing the standard.

> My question 5 is about whether the standard itself requires that subsequent 
> attempts to set errexit should be ignored, even assuming that errexit should 
> be turned off once in a while for the sake of the standard. The alternative 
> is that this is just a historical decision of bash that could be mended 
> without breaking compliance.

It does.  The text in the (still-published) version of Posix-2008 was
deemed to be wrong and not consistent with historical shell behavior;
this is the updated version:

http://austingroupbugs.net/view.php?id=52

The text in the first sentence of 2) implies that -e is ignored during
the execution of the commands in the listed contexts.  It doesn't matter
what you do to the -e option while it's ignored.  The shell will only pay
attention to the setting of -e, whatever it is, when it's no longer
executing in a context where -e is ignored.  There is consensus among
Posix and current shell implementations about this.

There has been extensive discussion about this, some even on bug-bash:

http://lists.gnu.org/archive/html/bug-bash/2011-06/msg00080.html
http://lists.gnu.org/archive/html/bug-bash/2011-11/msg00125.html
http://lists.gnu.org/archive/html/bug-bash/2012-01/msg00111.html
http://lists.gnu.org/archive/html/bug-bash/2012-09/msg00014.html
http://lists.gnu.org/archive/html/bug-bash/2012-10/msg00049.html

There are bash users who are extremely vocal about their view that
the bash-4.2 behavior, which was modified extensively to implement
what Posix says and what historical shells do, is wrong, so you are
not alone.

> If indeed the standard requires all further attempts to set errexit be 
> ignored (which I think is a terrible idea), wouldn't it be a good idea to 
> provide in bash another option doing the same thing, but correctly? Something 
> like set -o strong_errexit, something that anybody writing a new script can 
> choose to use or not, of course understanding that it is a bashism, but the 
> right kind of bashism.

There is already a proposal for a new option similar to what you want; you
can read the discussion at

http://austingroupbugs.net/view.php?id=537

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