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...
