On Wed, 19 Jun 2013, Trent W. Buck wrote:
Matthew Cengia <mattcen@gmail.com> writes:
http://mywiki.wooledge.org/BashFAQ/105 (subshells in bash don't always inherit "set -e" from the parent. This WFM, YMMV, #bash doesn't like it. What's their problem with it?
They think set -e is too confusing and you should ||die on every line.
I unfortunately decided that set -e wasn't ever going to do the job portably enough (where enough is defined for our purposes to be RHEL4,5&6), and fell back to die on every important line. Nuts. My idea of correct and damn obvious and should be unambiguous in POSIX but everyone probably disagrees with because obvious things are always contentious and seen from different points of view, is that the subshell shouldn't do anything special at all. It should just be a fork() of the parent bash. set -e should remain as set (perhaps rely on -E from my reading, but I would have assumed -E was the default). calling: set -e foo() { false echo moo true echo cow } bar=`foo` should exit straight away with exit code 1 with no moo, no cow. foo never got to print anything, and bar never got assigned because the exit happened before then. This (untested, but seems to be approximately be what I was testing 5 hours ago) and variations therein behave completely differently depending on bash version. It should have been so damn easy. Instead I get nothing output and exit code 0 (here, siggy!). Maybe it would be best if the SOE they're trying to push out to all govt agencies removes our right to execve() /bin/bash. -- Tim Connors "The application did not fail successfully because of an error"