Just a warning if you're writing shell scripts...

http://mywiki.wooledge.org/BashFAQ/105 (subshells in bash don't always inherit "set -e" from the parent. depending on bash version, whether posix is set, and the current phase of the 16th moon of Jupiter. And some idiot thought it was a feature to remove this functionality at some point because it was ambiguously worded in POSIX, so make it never ever work. silently.) If you frequently use "set -e" (aka "set -o errexit"), so that you don't have to explicitly check every error code, because you want something to fail immediately rather than potentially cause havok down the line because you accidentally missed one exception check, then don't. Every short little bash script you write is eventually going to become a convoluted mess anyway, so you might as well start off in Perl and be done with it. It's too late for me, but save yourself! -- Tim Connors

Tim Connors <tconnors@rather.puzzling.org> 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. #!/bin/bash ## Program description goes here # Boilerplate prelude ################################################ set -eEu set -o pipefail trap 'echo >&2 "$0: unknown error"' ERR while getopts d opt do case "$opt" in (x) set -x;; ('?') exit 1;; esac done shift $((${OPTIND:-1}-1)) # Begin code #########################################################

On 2013-06-19 17:29, Trent W. Buck wrote:
Tim Connors <tconnors@rather.puzzling.org> 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.
#!/bin/bash ## Program description goes here # Boilerplate prelude ################################################ set -eEu set -o pipefail trap 'echo >&2 "$0: unknown error"' ERR while getopts d opt do case "$opt" in (x) set -x;; ('?') exit 1;; esac done shift $((${OPTIND:-1}-1)) # Begin code #########################################################
What's their problem with it? -- Regards, Matthew Cengia

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.

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"
participants (4)
-
Matthew Cengia
-
Tim Connors
-
Trent W. Buck
-
trentbuck@gmail.com