Bash – How to make bash abort the execution of a script on syntax error

basherror handlingshell-script

To be on safe side, I'd like bash abort the execution of a script if it encounters a syntax error.

To my surprise, I can't achieve this. (set -e is not enough.) Example:

#!/bin/bash

# Do exit on any error:
set -e

readonly a=(1 2)

# A syntax error is here:

if (( "${a[#]}" == 2 )); then
    echo ok
else
    echo not ok
fi

echo status $?

echo 'Bad: has not aborted execution on syntax error!'

Result (bash-3.2.39 or bash-3.2.51):

$ ./sh-on-syntax-err
./sh-on-syntax-err: line 10: #: syntax error: operand expected (error token is "#")
status 1
Bad: has not aborted execution on syntax error!
$

Well, we can't check $? after every statement to catch syntax errors.

(I expected such safe behavior from a sensible programming language… perhaps this must be reported as a bug/wish to bash developers)

More experiments

`if` makes no difference.

Removing if:

#!/bin/bash

set -e # exit on any error
readonly a=(1 2)
# A syntax error is here:
(( "${a[#]}" == 2 ))
echo status $?
echo 'Bad: has not aborted execution on syntax error!'

Result:

$ ./sh-on-syntax-err 
./sh-on-syntax-err: line 6: #: syntax error: operand expected (error token is "#")
status 1
Bad: has not aborted execution on syntax error!
$

Perhaps, it's related to exercise 2 from http://mywiki.wooledge.org/BashFAQ/105 and has something to do with (( )). But I find it still unreasonable to continue executing afte a syntax error.

No, `(( ))` makes no difference!

It behaves bad even without the arithmetic test! Just a simple, basic script:

#!/bin/bash

set -e # exit on any error
readonly a=(1 2)
# A syntax error is here:
echo "${a[#]}"
echo status $?
echo 'Bad: has not aborted execution on syntax error!'

Result:

$ ./sh-on-syntax-err 
./sh-on-syntax-err: line 6: #: syntax error: operand expected (error token is "#")
status 1
Bad: has not aborted execution on syntax error!
$

Best Answer

Wrapping the whole into a function seems to do the trick:

#!/bin/bash -e

main () {
readonly a=(1 2)
    # A syntax error is here:
    if (( "${a[#]}" == 2 )); then
        echo ok
    else
        echo not ok
    fi
    echo status $?
    echo 'Bad: has not aborted execution on syntax error!'
}

main "$@"

Result:

$ ./sh-on-syntax-err 
$ ./sh-on-syntax-err line 6: #: syntax error: operand expected (error token is "#")
$

Though I have no clue why - maybe someone else can explain?

Related Solutions

Bash Scripting – Correct Behavior of EXIT and ERR Traps with set -eu

From man bash:

set -u
- Treat unset variables and parameters other than the special parameters "@" and "*" as an error when performing parameter expansion. If expansion is attempted on an unset variable or parameter, the shell prints an error message, and, if not -interactive, exits with a nonzero status.

POSIX states that, in the event of an expansion error, a non-interactive shell shall exit when the expansion is associated with either a shell special builtin (which is a distinction bash regularly ignores anyway, and so maybe is irrelevant) or any other utility besides.

Consequences of Shell Errors:
- An expansion error is one that occurs when the shell expansions defined in Word Expansions are carried out (for example, "${x!y}", because ! is not a valid operator); an implementation may treat these as syntax errors if it is able to detect them during tokenization, rather than during expansion.
- [A]n interactive shell shall write a diagnostic message to standard error without exiting.

Also from man bash:

trap ... ERR
- If a sigspec is ERR, the command arg is executed whenever a pipeline (which may consist of a single simple command), a list, or a compound command returns a non-zero exit status, subject to the following conditions:
  - 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 command executed in a && or || list except the command following the final && or ||...
  - ...any command in a pipeline but the last...
  - ...or if the command's return value is being inverted using !.
- These are the same conditions obeyed by the errexit -e option.

Note above that the ERR trap is all about the evaluation of some other command's return. But when an expansion error occurs, there is no command run to return anything. In your example, echo never happens - because while the shell evaluates and expands its arguments it encounters an -unset variable, which has been specified by explicit shell option to cause an immediate exit from the current, scripted shell.

And so the EXIT trap, if any, is executed, and the shell exits with a diagnostic message and exit status other than 0 - exactly as it should do.

As for the rc: 0 thing, I expect that is a version specific bug of some kind - probably to do with the two triggers for the EXIT occurring at the same time and the one getting the other's exit code (which should not occur). And anyway, with an up-to-date bash binary as installed by pacman:

bash <<\IN
    printf "shell options:\t$-\n"
    trap 'echo "EXIT (rc: $?)"' EXIT
    set -eu
    echo ${UNSET_VAR}
IN

I added the first line so you can see that the shell's conditions are those of a scripted shell - it is not interactive. The output is:

shell options:  hB
bash: line 4: UNSET_VAR: unbound variable
EXIT (rc: 1)

Here are some relevant notes from recent changelogs:

Fixed a bug that caused asynchronous commands to not set $? correctly.
Fixed a bug that caused error messages generated by expansion errors in for commands to have the wrong line number.
Fixed a bug that caused SIGINT and SIGQUIT to not be trappable in asynchronous subshell commands.
Fixed a problem with interrupt handling that caused a second and subsequent SIGINT to be ignored by interactive shells.
The shell no longer blocks receipt of signals while running trap handlers for those signals, and allows most trap handlers to be run recursively (running trap handlers while a trap handler is executing).

I think it is either the last or the first that is most relevant - or possibly a combination of the two. A trap handler is by its very nature asynchronous because its whole job is to wait for and handle asynchronous signals. And you trigger two simultaneously with -eu and $UNSET_VAR.

And so maybe you should just update, but if you like yourself, you'll do it with a different shell altogether.

Bash Arrays – Using Variables in Array Names

Some ideas:

A "parameter expansion" of a variable value (the ${...} part):
```
echo "arr$COUNTER[0] = ${arr$COUNTER[0]}"
```
will not work. You may get around by using eval (but I do not recommend it):
```
eval echo "arr$COUNTER[0] = \${arr$COUNTER[0]}"
```
That line could be written as this:
```
i="arr$COUNTER[0]"; echo "$i = ${!i}"
```
That is called indirection (the !) in Bash.
A similar issue happens with this line:
```
declare -a "arr$COUNTER=($field)"
```
Which should be split into two lines, and eval used:
```
declare -a "arr$COUNTER"
eval arr$COUNTER\=$ \$field $
```
Again, I do not recommend using eval (in this case).
As you are reading the whole file into the memory of the shell, we may as well use a simpler method to get all lines into an array:
```
readarray -t lines <"VALUES_FILE.txt"
```
That should be faster than calling awk for each line.

An script with all the above could be:

#!/bin/bash
valfile="VALUES_FILE.txt"

readarray -t lines <"$valfile"             ### read all lines in.

line_count="${#lines[@]}"
echo "Total number of lines $line_count"

for ((l=0;l<$line_count;l++)); do
    echo "Counter value is $l"             ### In which line are we?
    echo "Field = ${lines[l]}"             ### kepth only to help understanding.
    k="arr$l"                              ### Build the variable arr$COUNTER
    IFS=" " read -ra $k <<<"${lines[l]}"   ### Split into an array a line.
    eval max=\${#$k[@]}                    ### How many elements arr$COUNTER has?
    #echo "field $field and k=$k max=$max" ### Un-quote to "see" inside.
    for ((j=0;j<$max;j++)); do             ### for each element in the line.
        i="$k[$j]"; echo "$i = ${!i}"      ### echo it's value.
    done
done
echo "The End"
echo

However, still, AWK may be faster, if we could execute what you need in AWK.

A similar processing could be done in awk. Assuming the 6 values will be used as an IP (4 of them) and the other two are a number and an epoch time.

Just a very simple sample of an AWK script:

#!/bin/sh
valfile="VALUES_FILE.txt"
awk '
NF==6 { printf ( "IP: %s.%s.%s.%s\t",$1,$2,$3,$4)
        printf ( "number: %s\t",$5+2)
        printf ( "epoch: %s\t",$6)
        printf ( "\n" )
    }
' "$valfile"

Just make a new question with the details.

More experiments

if makes no difference.

No, (( )) makes no difference!

Best Answer

Related Solutions

Bash Scripting – Correct Behavior of EXIT and ERR Traps with set -eu

Bash Arrays – Using Variables in Array Names

Related Question

`if` makes no difference.

No, `(( ))` makes no difference!