Re: [Help-bash] [Resolved. Thanks!] Strange behaviour of trap ERR. (( x = 0 )) is an error?

[Andrew S]

Team,


Thanks to those who replied.

I was glad for the explanations and links to relevant posts and articles.

I fixed up my script, and all is well.


--

Andrew



________________________________
From: Help-bash <address@hidden> on behalf of address@hidden <address@hidden>
Sent: September 3, 2017 12:00 PM
To: address@hidden
Subject: Help-bash Digest, Vol 71, Issue 3

Send Help-bash mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/help-bash
Help-bash Info Page - GNU<https://lists.gnu.org/mailman/listinfo/help-bash>
lists.gnu.org
Bash is the GNU Project's Bourne Again SHell. This list is for asking questions 
about bash and shell programming. Also available is address@hidden for general 
...



or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Help-bash digest..."


Today's Topics:

   1. Strange behaviour of trap ERR. (( x = 0 )) is an error? (Andrew S)
   2. Re: Strange behaviour of trap ERR. (( x = 0 )) is an error?
      (Eduardo Bustamante)
   3. Re: Strange behaviour of trap ERR. (( x = 0 )) is an error?
      (Pierre Gaston)


----------------------------------------------------------------------

Message: 1
Date: Sat, 2 Sep 2017 15:54:32 +0000
From: Andrew S <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Help-bash] Strange behaviour of trap ERR. (( x = 0 )) is an
        error?
Message-ID:
        <address@hidden>

Content-Type: text/plain; charset="iso-8859-1"

Team,

I have a large BASH script that uses 'trap this_func ERR' construct for error
trapping.  It's been running well for years on an old Linux server.
It's being moved to a new server with a newer version of BASH.
On the new server, the ERR trap is not working as expected.
On the new server, (( x = 0 )) fires the trap.  I don't understand.

Here is a script to illustrate the problem:
---------- Script below ----------
#!/bin/bash

function ERR_trap()
{
    echo "Error!"
    echo "while executing ${BASH_COMMAND}"
}

# Main
echo "BASH=[${BASH}]"
echo "BASH_VERSION=[${BASH_VERSION}]"
echo "BASHOPTS=[${BASHOPTS}]"
echo ""
echo "HOSTTYPE=[${HOSTTYPE}]"
echo "MACHTYPE=[${MACHTYPE}]"
echo "OSTYPE=[${OSTYPE}]"
echo "redhat-release"
cat /etc/redhat-release
echo ""
echo "SHELL=[${SHELL}]"
echo "SHELLOPTS=[${SHELLOPTS}]"
echo ""

echo "ERR trap not set yet."
echo ""

# Set a variable to 0.  This will not throw a trap yet.
echo "setting (( x = 0 ))"
(( x = 0 ))
echo ""

echo "x=[${x}]"
echo ""

# enable the error trap
echo "setting ERR trap"
trap ERR_trap ERR
echo "ERR trap set."
echo ""

# set a variable to something other than 0, and there is no trouble.
echo "setting (( answer = 42 ))"
(( answer = 42 ))
echo ""

echo "answer=[${answer}]"
echo ""

# set a variable to 0
# For some reson, this causes the ERR trap to fire.
echo "setting (( something = 0 ))"
(( something = 0 ))
echo ""

echo "something=[${something}]"
echo ""

---------- Script above ----------

Below is a sample run of the script on each server.

---------- Old Server run below ----------
address@hidden:~ $ errExample.sh
BASH=[/bin/bash]
BASH_VERSION=[3.00.15(1)-release]
BASHOPTS=[]

HOSTTYPE=[i386]
MACHTYPE=[i386-redhat-linux-gnu]
OSTYPE=[linux-gnu]
redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 9)

SHELL=[/bin/bash]
SHELLOPTS=[braceexpand:hashall:interactive-comments]

ERR trap not set yet.

setting (( x = 0 ))

x=[0]

setting ERR trap
ERR trap set.

setting (( answer = 42 ))

answer=[42]

setting (( something = 0 ))

something=[0]


address@hidden:~ $

---------- Old server run above ----------

---------- New server run below ----------
address@hidden:~ $ errExample.sh
BASH=[/bin/bash]
BASH_VERSION=[4.1.2(1)-release]
BASHOPTS=[cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath]

HOSTTYPE=[x86_64]
MACHTYPE=[x86_64-redhat-linux-gnu]
OSTYPE=[linux-gnu]
redhat-release
Red Hat Enterprise Linux Server release 6.9 (Santiago)

SHELL=[/bin/bash]
SHELLOPTS=[braceexpand:hashall:interactive-comments]

ERR trap not set yet.

setting (( x = 0 ))

x=[0]

setting ERR trap
ERR trap set.

setting (( answer = 42 ))

answer=[42]

setting (( something = 0 ))
Error!
while executing (( something = 0 ))

something=[0]


address@hidden:~ $

---------- New server run above ----------

Questions:
Why does (( x = 0 )) fire the ERR trap on the new server?
What can I do to stop (( x = 0 )) from being an error?
Is there a shell option I have set funny?

Thanks in advance for your help.

--
Respectfully,

Andrew


------------------------------

Message: 2
Date: Sat, 2 Sep 2017 09:42:34 -0700
From: Eduardo Bustamante <address@hidden>
To: Andrew S <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Help-bash] Strange behaviour of trap ERR. (( x = 0 )) is
        an error?
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="UTF-8"

On Sat, Sep 2, 2017 at 8:54 AM, Andrew S <address@hidden> wrote:
[...]
> BASH_VERSION=[3.00.15(1)-release]
[...]
> BASH_VERSION=[4.1.2(1)-release]

> Questions:
> Why does (( x = 0 )) fire the ERR trap on the new server?
> What can I do to stop (( x = 0 )) from being an error?
> Is there a shell option I have set funny?

FWIW, 4.1.2 is not new. It's from 2009. And 3.0.16 (which means that
the one you were using is even older) is from 2005.

(( x = 0 )) fires the ERR trap, because it's return code is greater
than 0. Which you can see here:

$ (( x = 0 )); echo $?
1

The reason is simple. Both `let' and `((' commands return 0 if the
arithmetical expression evaluates to `expr != 0', otherwise, they
return 1. This is used in constructs like:

if (( expr )); then ...; fi
while (( expr )); then ...; fi

It seems bash 3.0.16 was buggy, because does not exit after the `(('
command returns an error code.

$ ./bash -ec 'echo $BASH_VERSION; (( 0 )); echo $?'
3.00.16(2)-release
1

$ bash -ec 'echo $BASH_VERSION; (( 0 )); echo $?'
4.4.12(1)-release

There's not much you can do here, other than to turn off the ERR trap,
or to disable the errexit/ERR behavior for that particular command
with something like this:

$ bash -ec 'echo $BASH_VERSION; (( 0 )) && :; echo $?'
4.4.12(1)-release
1



------------------------------

Message: 3
Date: Sat, 2 Sep 2017 19:45:53 +0300
From: Pierre Gaston <address@hidden>
To: Eduardo Bustamante <address@hidden>
Cc: Andrew S <address@hidden>, "address@hidden"
        <address@hidden>
Subject: Re: [Help-bash] Strange behaviour of trap ERR. (( x = 0 )) is
        an error?
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="UTF-8"

On Sat, Sep 2, 2017 at 7:42 PM, Eduardo Bustamante <address@hidden>
wrote:

> On Sat, Sep 2, 2017 at 8:54 AM, Andrew S <address@hidden> wrote:
> [...]
> > BASH_VERSION=[3.00.15(1)-release]
> [...]
> > BASH_VERSION=[4.1.2(1)-release]
>
> > Questions:
> > Why does (( x = 0 )) fire the ERR trap on the new server?
> > What can I do to stop (( x = 0 )) from being an error?
> > Is there a shell option I have set funny?
>
> FWIW, 4.1.2 is not new. It's from 2009. And 3.0.16 (which means that
> the one you were using is even older) is from 2005.
>
> (( x = 0 )) fires the ERR trap, because it's return code is greater
> than 0. Which you can see here:
>
> $ (( x = 0 )); echo $?
> 1
>
> The reason is simple. Both `let' and `((' commands return 0 if the
> arithmetical expression evaluates to `expr != 0', otherwise, they
> return 1. This is used in constructs like:
>
> if (( expr )); then ...; fi
> while (( expr )); then ...; fi
>
> It seems bash 3.0.16 was buggy, because does not exit after the `(('
> command returns an error code.
>
> $ ./bash -ec 'echo $BASH_VERSION; (( 0 )); echo $?'
> 3.00.16(2)-release
> 1
>
> $ bash -ec 'echo $BASH_VERSION; (( 0 )); echo $?'
> 4.4.12(1)-release
>
> There's not much you can do here, other than to turn off the ERR trap,
> or to disable the errexit/ERR behavior for that particular command
> with something like this:
>
> this was changed in 4.1 there is relevant thread
http://lists.gnu.org/archive/html/bug-bash/2016-08/msg00061.html

if you assign you can do var=$((...)) instead of ((var=....))


------------------------------

Subject: Digest Footer

_______________________________________________
Help-bash mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/help-bash
Help-bash Info Page - GNU<https://lists.gnu.org/mailman/listinfo/help-bash>
lists.gnu.org
Bash is the GNU Project's Bourne Again SHell. This list is for asking questions 
about bash and shell programming. Also available is address@hidden for general 
...





------------------------------

End of Help-bash Digest, Vol 71, Issue 3
****************************************