On 6/22/10 12:51 AM, Andres P wrote:
> Bash 4.1 does not set the ERR trap:
It does, but remember that the ERR trap is only executed under the
circumstances that would cause the shell to exit when set -e is enabled.
>
> $ env -i HOME="$HOME" TERM="$TERM" bash3 <<\!
>
> set -o errexit
> set -o errtrace
>
> TRIGGERED_ERR() { return $?; }
>
> trap 'TRIGGERED_ERR' ERR
>
> set -o xtrace
>
> var=$(false) || true
> echo $?
>
> var=$(false || true) # only way of not triggering it...
> echo $?
>
> !
>
> ++ false # Subshell false
> +++ TRIGGERED_ERR # Ignores outer "|| true"
> +++ return 1
> + var=
> + true
> + echo 0
> 0 # But the entire command line does
> # not set off errexit
> ++ false
> ++ true # Predictable second subshell...
> + var=
> + echo 0
> 0
>
>
> Before I write a patch, is this bug documented? I could not find it in
> the archives.
>
> Is it a bug at all or is it expected behaviour?
One of the changes between bash-3.2 and bash-4.0 was to make command
substitution understand when it was being executed in a context where
the return value would be ignored, and to ignore any inherited setting
of -e and the ERR trap in those cases. This was part of the big change
in the behavior of set -e in response to the consensus of the Posix
working group, and more directly the result of a bug report.
> The ERR trap is not executed if the failed command is part of the command
> list immediately following a while or until keyword, part of the test in an
> if statement, part of a && or ⎪⎪ list, or if the command's return value is
> being inverted via !
The exit status of the command substitution will ultimately be ignored
because it's part of an assignment statement on the LHS of a || list, so
the commands run in the command substitution inherit that state.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
