Re: Function code breaking out of if then ...fi

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

n Fri, 02 Nov 2012 14:39:11 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

> On Nov 2, 10:09am, Michal Maruska wrote:
> }
> } I wonder if the following behaviour is a bug, or
> } simply my wrong expectation:
> } 
> } This script, assuming the globbing fails, and I'm not using
> NULL_GLOB, } does not bother finishing the commands in the
> "then ....fi" block, } instead continues after "fi".
> 
> What slightly surprises me is that a glob failure isn't considered an
> error for purposes of ERR_EXIT (the -e option in your #! line).  I
> would have expected the whole script to quit at that point, but I
> guess glob errors are not treated as command failures because the
> command never executes in the first place.
> 
> However, what *is* happening is that a glob failure in a complex
> command acts in the manner of a "break" statement.

It's not really like a break, it's like (well, is) a global error flag
--- but the error status gets reset at the top level command loop, which
we reach in a script after the end of a set of complex commands --- but
only right at the end, when we're reading a new (possibly complex,
arbitrarily nested) command from the script.

I think actually what's going on could be considered a bug which is an
oversight for the case of scripts.  If the code was running a function,
the failure would cause it to skip right to the end of the function,
indeed any arbitrarily nested hierarchy of functions.  If we took the
rough equivalence between functions and scripts seriously, any hard
error (zerr() or zerrnam()) would cause a script to exit in the same
way.  Interactively, the error flag would still get reset but
non-interactively it wouldn't.

I don't see anything in the documentation to suggest that the top-level
command loop should be special non-interactively in the way it currently
is.  Indeed, when documenting try- and always-blocks, I wrote:

  An `error' in this context is a condition such as a syntax error
  which causes the shell to abort execution of the  current  func‐
  tion,  script,  or  list.
         ^^^^^^

which is clearly not true.  If there's a more fundamental description
of what happens on an error, I don't know where it is.

Indeed, it looks to me that without this the shell is violating the
"shall exit" terms of POSIX, section 2.8.1 of the shell command
language.  To use the example they give, this script

echo "${x!y}"
echo Got here

shouldn't print anything apart from the error message, but does.

pws