bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

-e does not work inside subscript when using || or && operator outside


From: Christian Jaeger
Subject: -e does not work inside subscript when using || or && operator outside
Date: Wed, 06 Aug 2008 13:13:34 +0200

(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 address@hidden)

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]