On Wed, 19 Jun 2013, Trent W. Buck wrote:
> Matthew Cengia <[email protected]> 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"
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main
