Re: executes statement after "exit"

[Alex fxmbsw7 Ratchev]

dude u didnt get, in your example : is already the cmd
therenis no 'exit cmd' in your code
only exit as arg to :

On Fri, Apr 15, 2022, 20:36 Frank Heckenbach <f.heckenbach@fh-soft.de>
wrote:

> > > #!/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 ...
>
>