On 02/08/2012 04:31 PM, Linda Walsh wrote: > More people need to stop being part of the problem and realize that > just because some people say things that don't appear to be pleasant, > doesn't mean they are not true -- they may simply lack the ability to > dissemble as well as others -- a > large disadvantage in today's society.
Rather than whining about bash complying to standards that you think are less than stellar, you can join the Austin Group and help become part of the solution of improving those standards. Membership does not cost any money. Right now, there is a proposal on the floor to add a new 'set' option to the shell that would give 'set -e' the ability to be turned back on in contexts where the historical ksh88 (and thus POSIX 2008 wording) required it to be silently ignored. http://austingroupbugs.net/view.php?id=537 | If anything, the way to go about this would be to keep 'set -e' unchanged in behavior by default, where there are contexts (such as functions) where reusing 'set -e' has no effect because of the calling context; and then go about getting consensus among the various shell implementers about adding a new set option (maybe named 'set -o errreset'; good luck in finding a short option name that works for all the shells) that lifts the restriction about contexts where 'set -e' is ignored. That is: | | f() { set -e; false; echo hello; }; if f; then :; fi | | would continue to echo hello, but: | | f() { set -e; false; echo hello; }; set -o errreset; if f; then :; fi | | would let the set -e inside f() take effect, and inhibit the echo. By doing this, scripts written to the behavior of 0000052 will continue to work, and new scripts can opt-in to the more intuitive semantics. I suggest you read up on this, chime in with your thoughts, or even better, chime in with patches to bash (bash is free software with open source, after all). And if you'll read carefully, you might even recognize that I was the one that wrote that particular comment on the Austin Group bug page. In other words, I agree that the current behavior of 'set -e' is unintuitive, but I also feel strongly that the only way to improve things without breaking existing scripts that have come to rely upon the documented effects of 'set -e' is to add a new option, where users can opt-in to more-intuitive behavior. Now, exactly what that behavior should be, and how to write it up in standardese, is where we need assistance from you, as the end user, to help develop a working prototype of the new shell option, and make sure that it meets your needs, before making it part of the next version of POSIX. It's a lot easier to standardize something with a reference implementation, after all. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
