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

[Andrew S]

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 ----------
***@MSBCRS:~ $ 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]


***@MSBCRS:~ $

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

---------- New server run below ----------
***@puniaucrs010:~ $ 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]


***@puniaucrs010:~ $

---------- 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

[Eduardo Bustamante]

On Sat, Sep 2, 2017 at 8:54 AM, Andrew S <***@hotmail.com> wrote:
[...]

Post by Andrew S
BASH_VERSION=[3.00.15(1)-release]

[...]

Post by Andrew S
BASH_VERSION=[4.1.2(1)-release]
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

[Pierre Gaston]

Post by Eduardo Bustamante
[...]

Post by Andrew S
BASH_VERSION=[3.00.15(1)-release]

[...]

Post by Andrew S
BASH_VERSION=[4.1.2(1)-release]
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
$ (( x = 0 )); echo $?
1
The reason is simple. Both `let' and `((' commands return 0 if the
arithmetical expression evaluates to `expr != 0', otherwise, they
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
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=....))

[Greg Wooledge]

Post by Pierre Gaston
if you assign you can do var=$((...)) instead of ((var=....))

Or in this case, simply x=0

See also http://mywiki.wooledge.org/BashFAQ/105