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

[matei . david]

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.

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.

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.

Also, my questions 1-3 relate to the current implementation...