On 12/15/12 11:54 AM, matei.da...@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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
