On Fri, Apr 8, 2022, at 3:23 PM, Chet Ramey wrote:
> 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.
Notably, these don't execute "echo b" either, demonstrating that
this isn't actually about functions at all.
{
echo a
echo "$[ 1 + ]"
echo b
}
echo a; echo "$[ 1 + ]"; echo b
> (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.)
*pipes* :)
Consequently, a modernized testfail2 using $((...)) notation doesn't
execute "echo b" when run with ksh, dash, yash, or POSIX-mode bash
(or even native-mode zsh).
--
vq
