On 6/22/10 3:10 PM, Andres P wrote:
>> 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.
>>
>
> Thanks, this behaviour seemed strang
On Tue, Jun 22, 2010 at 2:21 PM, Chet Ramey wrote:
> 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.
>
To clarify, I meant
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
At Tuesday 22 June 2010, Andres P wrote:
> On Tue, Jun 22, 2010 at 4:45 AM, Stefano Lattarini
>
> wrote:
> >> ++ false # Subshell false
> >> +++ TRIGGERED_ERR # Ignores outer "|| true"
> >
> > No, it doesen't even see it; the script seen by the subshell
> > consists just of the string
On Tue, Jun 22, 2010 at 4:45 AM, Stefano Lattarini
wrote:
>> ++ false # Subshell false
>> +++ TRIGGERED_ERR # Ignores outer "|| true"
> No, it doesen't even see it; the script seen by the subshell consists
> just of the string "false", so there is no `||' the subshell can see.
> And thi
At Tuesday 22 June 2010, Andres P wrote:
> Bash 4.1 does not set the ERR trap:
>
> $ 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
Here, the subs
Bash 4.1 does not set the ERR trap:
$ 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 $?
!
++
