bug with 'set -e' + 'trap 0' + syntax error
I have the following scripts: $ cat nobug.sh trap 'e=$?; [ $e -gt 0 ] && echo "OK" || echo "BAD"; exit $e' 0 # syntax error here && true $ cat bug.sh set -e trap 'e=$?; [ $e -gt 0 ] && echo "OK" || echo "BAD"; exit $e' 0 # syntax error here && true I thought that when bash detect a syntax errors in a script, it would pass a $? != 0 to the code in the exit trap, regardless of whether `set -e' is active or not. But if I run bug.sh with either bash-3.2 or bash-4.0, I get: $ bash bug.sh; echo $? bug.sh: line 4: syntax error near unexpected token `&&' BAD 0 On the other hand: $ bash nobug.sh; echo $? nobug.sh: line 4: syntax error near unexpected token `&&' nobug.sh: line 4: `&& true' OK 2 $ dash bug.sh; echo $? # Debian Alquist shell, version 0.5 bug.sh: 4: Syntax error: "&&" unexpected OK 2 $ zsh bug.sh; echo $? # Zsh, version 4.3 nobug.sh:4: parse error near `&&' OK 1 I think this can be classified as a bug in bash (in some situations, a very nasty one). Please let me know if I have misunderstood something, or if there is a simple workaround. More details about my environment and bash versions follow... --- Details on operating system: $ uname -s -r -m -o Linux 2.6.26-1-686 i686 GNU/Linux $ lsb_release -i -d -r -c Distributor ID: Debian Description: Debian GNU/Linux testing/unstable Release: testing/unstable Codename: n/a $ cat /etc/debian_version squeeze/sid --- Details on bash versions: Bash 4.0 --- Installed by hand from official tarball Complete version string: 4.0.0(1)-release Information from bashbug [Automatically generated]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/opt/bleedingedge/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I.. -I../include -I../lib -g -O2 Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 0 Release Status: release Bash 3.2 --- Installed from debian package "bash", version "3.2-6" Complete version string: 3.2.48(1)-release Information from bashbug [Automatically generated]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 48 Release Status: release ---
Re: bug with 'set -e' + 'trap 0' + syntax error
Stefano Lattarini a écrit : > I thought that when bash detect a syntax errors in a script, > it would pass a $? != 0 to the code in the exit trap, regardless > of whether `set -e' is active or not. > > I think this can be classified as a bug in bash (in some > situations, a very nasty one). Please let me know if I > have misunderstood something, or if there is a simple > workaround. I am not familiar with the standard(s), but... isn't having expectations in the case of syntax errors a bit far-fetched?
Re: bug with 'set -e' + 'trap 0' + syntax error
> Stefano Lattarini a écrit : > > I thought that when bash detect a syntax errors in a script, > > it would pass a $? != 0 to the code in the exit trap, regardless > > of whether `set -e' is active or not. > > > > [CUT] > > > > I think this can be classified as a bug in bash (in some > > situations, a very nasty one). Please let me know if I > > have misunderstood something, or if there is a simple > > workaround. > > I am not familiar with the standard(s), but... isn't having > expectations in the case of syntax errors a bit far-fetched? > Well, I'd not expect that the exit trap is executed flawlessly, and not even that it is executed at all, but at least the shell should abort the script and exit with a non-zero status. This is a much more rational approach than having the flawed script exiting sucessfully, IMHO. In fact, I've been bitten by this "bug" (or limitation) when a stupid syntax error leaked in some scripts part of a testsuite (that was my fault). The scripts erroneously apperead as PASS'd, while they should have been marked as FAIL'd -- a vary bad thing in my opinion. And I discovered the bug only when I tried to run the testsuite with dash, to check its "portability". Aside that, the exit trap executes correctly even on bash when `set -e' is not active, which makes the described behaviour seeming more a bug rather than a limitation. By the way, sorry for the duplicate message. Regards, Stefano
