Re: Bug in Bash on syntax error in functions?

[Chet Ramey]

On 4/8/22 2:42 AM, Roel Van de Paar via Bug reports for the GNU Bourne 
Again SHell wrote:
> Hi!
>
> I am using GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu).
>
> Here is what looks to be a bug:

It's not. There are a couple of misconceptions here. Let's go through them.

------------------------------------------------------------------------------------------
> $ cat testfail1
> #!/bin/bash
> echo 'a'
> fail_command
> echo 'b'

First, command not found is not a shell syntax error or word expansion
error. It simply causes $? to be set to 127.

> $ cat testfail2
> #!/bin/bash
> echo 'a'
> echo "$[ 1 + ]"
> echo 'b'

Next, this is not a shell syntax error either, it is a word expansion
error (the error is that the arithmetic expression is missing an operand;
the word expansion is the obsolete $[ ... ]).

> $ cat testfail3
> #!/bin/bash
> function1(){
>    echo 'a'
>    fail_command
>    echo 'b'
> }
> function1
> echo "exit: $?"
> $ cat testfail4
> #!/bin/bash
> function1(){
>    echo 'a'
>    echo "$[ 1 + ]"
>    echo 'b'
> }
> function1
> echo "exit: $?"

These simply wrap the above in a brace group command that is the shell
function body.

So the difference is between a command not found

> $ ./testfail1
> a
> ./testfail1: line 3: fail_command: command not found
> b
> $ ./testfail2
> a
> ./testfail2: line 3: 1 + : syntax error: operand expected (error token is
> "+ ")
> b

and a word expansion error. Command-not-found errors don't really have any
effect on execution unless you have the `-e' option set. Word expansion
errors cause the shell to abort the currently-executing command (in this
case, a simple command) and return to the top level read-execute loop.

(And before someone pipes up here, POSIX requires a non-interactive shell
to exit immediately on a word expansion error, which bash does in posix
mode.)

> $ ./testfail3
> a
> ./testfail3: line 4: fail_command: command not found
> b
> exit: 0
> $ ./testfail4
> a
> ./testfail4: line 4: 1 + : syntax error: operand expected (error token is
> "+ ")
> exit: 1
> $
> ------------------------------------------------------------------------------------------
>
> Here is what is inconsistent:
> 1) testfail4 performs differently from testfail3 in that the function
> immediately terminates when a syntax error is found, even though both
> scripts have a failing command on the same line. Note testfail3 continues
> to execute whereas testfail4 does not, even in the case of nested functions
> [1]

The word expansion error causes the shell to abort execution of the current
command (the group command that is the function body) and return to the
top level read-execute loop. The command-not-found error isn't a shell
error and does not have that effect.

> 2) testfail4 performs differently from testfail2 in that when the syntax
> error is found a function, that function terminates, whereas if the same
> syntax error is in the main part of the script, that script continues to
> execute

See above.

> [1] Nested functions example: same outcome; all functions are immediately
> terminated

Same.

> This was worth a few hours of debugging in a large script running in a test
> server that oddly 'skipped code' when there was a calculation error, with
> the skipped code creating some undefined behaviour.

This is not a `calculation error'; this is a word expansion error.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/