bug-bash
[Top][All Lists]
Advanced

[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 ...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]