Re: set -e in (subshells) does not work independently of outer context

[Eric Blake]

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   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature