[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why does errexit exist in its current utterly useless form?
From: |
Chet Ramey |
Subject: |
Re: why does errexit exist in its current utterly useless form? |
Date: |
Sat, 15 Dec 2012 17:23:04 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 |
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/