(This is a resend because the gnu.org ml server didn't accept the
sender email address that was given by my mailing setup; the first
attempt has also been sent to [EMAIL PROTECTED])
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-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
uname output: Linux novo 2.6.26 #9 SMP Sat Jul 19 20:29:30 CEST 2008 x86_64
GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 3.2
Patch Level: 39
Release Status: release
Description:
Inside subscripts, -e handling is turned off or ignored if the ||
operator
This is reminding of the bug shown at
http://lists.gnu.org/archive/html/bug-bash/2008-01/msg00080.html
I always thought that the meaning of ( ) is to just fork, or
run the subscript as if it were run with bash -c '..' but
without the overhead of exec'ing a new shell in the forked
process. But these examples show that ( ) does not just fork.
Coming with a Perl background, I can even sort of understand
the behaviour at the above older bug report, namely that a
false-returning ( .. ) does not exit the shell, so as to let
one to examine $? manually (like $@ in perl after eval {
.. }), although I'm not exactly convinced this is such a good
idea (running if ( .. ); then echo $?; fi would still allow to
check for the reason in $?).
But now in this case I *have* to rely on the above weird
behaviour to be able to use -e at all, which makes the code
ugly, and one needs to get *two* things right to propagate
errors correctly (do not use || if one wants to check for the
error manually, and if one doesn't, *still* write an if
statement to check for $? explicitely).
Repeat-By:
$ bash -c '( set -e ; false; echo "hu?" ) || echo "false"'
hu?
# expecting "false"
$ bash -c '( set -e ; false; echo "hu?" ); if [ $? -ne 0 ]; then echo
"false"; fi'
false
# Also:
$ bash -c '( set -e ; false; echo "hu?" ) && echo "false"'
hu?
false
# expecting no output
Fix:
I don't know how to fix this in a way to make it backwards
compatible (if that's a concern), but if there's no way, I
suggest to document that clearly, preferably in a section
"quirks" or so.
