bug-bash
[Top][All Lists]
Advanced

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

trap ERR shows inconsistent behaviour


From: Henning Garus
Subject: trap ERR shows inconsistent behaviour
Date: Thu, 23 Jul 2009 13:03:26 -0700 (PDT)

Configuration Information [Automatically generated, do not change]:
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='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -march=i686 -mtune=generic -O2 
-pipe
uname output: Linux helios 2.6.30-ARCH #1 SMP PREEMPT Mon Jul 20 11:20:32 UTC 
2009 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 4.0
Patch Level: 24
Release Status: release

Description:
    When set -E is active functions inherit the ERR trap, however it will not
    be executed if the failed command is part of a comman executed in a ||
    list.

    If the failing command is part of a function, which is called as first
    part of ||, the ERR trap is not executed (call_func1), however if the 
function is
    called by eval it will be executed (call_func2).

    If trap 'return 1' ERR is set and the eval is wrapped in a list the second
    part of || will be executed(call_func3), without the list the trap will be 
executed
    again.

Repeat-By:
    set -E
    trap 'return $?' ERR

    func(){
        echo "entering func"
        false
        echo "after false"
    }

    call_func1() {
        echo 'PRE CALL func1||...'
        func || ret=$?
        echo "POST CALL "
    }

    call_func2() {
        echo 'PRE CALL eval func1||...'
        eval func || ret=$?
        echo "POST CALL $ret"
    }

    call_func3() {
        echo 'PRE CALL (eval func1)||...'
        (eval func) || ret=$?
        echo "POST CALL $ret"
    }


    call_func1
    call_func2
    call_func3

Fix:
    I am not sure if this is a bug, if this behaviour is intented a clarifying
    line in the description of trap would be useful. If not, is there any way
    to use "return $?" with the ERR trap, but stop it from completely 
unravelling the 
    call chain?




reply via email to

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