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.heckenb...@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 ... > >
