[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: executes statement after "exit"
From: |
Frank Heckenbach |
Subject: |
Re: executes statement after "exit" |
Date: |
Fri, 15 Apr 2022 20:34:49 +0200 |
> > #!/bin/bash
> > : $((08 + 0)); exit
> > echo "Should not get here."
>
> It never executes `exit'.
>
> The explanation in
> https://lists.gnu.org/archive/html/bug-bash/2022-04/msg00010.html applies
> here.
>
> The arithmetic syntax error (invalid octal constant) results in a word
> expansion error (the $((...)) ), which causes the shell to abort execution
> of the current command (the command list)
Current command means command list? Is this actually documented
somewhere?
E.g., in "3.5.6 Process Substitution" the manual says:
"The process list is run asynchronously, and its input or output
appears as a filename. This filename is passed as an argument to the
current command as the result of the expansion."
So if "current command" is the command list, in
sleep 3; : <(echo foo >&2)
shouldn't it start the "echo" before the "sleep" (in order to pass
its stdout as a filename to the command list)? It doesn't seem to do
so. So here, "current command" apparently means a simple command
(or in other cases, a compound command), but not a command list.
> and jump back to the top level
> to continue execution with the next command (echo).
Let't see. This is a command list, so according to your explanation,
due to the expansion error, neither the "exit" nor the "echo" is
run:
: $((08 + 0)); exit; echo "Should not get here."
Alright. Now, in "3.2.4 Lists of Commands" it says:
"A sequence of one or more newlines may appear in a list instead of a semicolon
to delimit commands."
So let's do this for the latter semicolon, resulting in:
: $((08 + 0)); exit
echo "Should not get here."
According to the above, this should still be one command list, so
the "echo" shouldn't run either, but it does.
> POSIX requires the shell to exit on a word expansion error, which bash does
> in posix mode.
This actually seems the saner behaviour rather than continuing at some
arbitrary point -- which I guess is well-defined in some sense, but
really unobvious to the programmer and very fragile since it changes
when a block is moved to a function, put inside an "if"-statement or
just has the formatting (";" vs. newline) changed ...