Re: zmv exits from function

[Bart Schaefer <schaefer@brasslantern.com>]

On Tue, Jan 2, 2024 at 10:16 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Yeah, I think I get it.  But the 'memo' has to be there -- zmv must ... or maybe not ... when zmv returns, if the 'always' keyword (sorta) it there, then it knows to not crash but to execute the following code.  So, yeah, it could be seen as 'linear'.

To avoid giving other readers a wrong conclusion ...

There are a number of failure cases defined by e.g. the POSIX
specification, or in some cases by longstanding zsh practice, that are
considered fatal errors.  When one of those errors is encountered,
whatever it is that the shell is doing, simply stops.  In a script,
this exits the entire script; in an interactive shell, it returns to
the top-level prompt.  In this specific example, there is no "zmv
returns":  it ends, full stop, no return value, nothing back to the
caller.  This is not a "crash", it's a well-defined exit condition.
(Whether it SHOULD be that condition specifically in zmv, is the topic
elsewhere in this thread.)  For a C equivalence, it's similar to
abort() having been called.

The "always" construct does nothing to the behavior of e.g. zmv, and
does not "memo" anything.  It allows calling code to intercept the
well-defined exit state and clean up.  (A "crash" would be an
unrecoverable condition in which not even "always" would be possible.)
 If the calling code does not intercept the exit state, then the
calling code also stops, and so on up the chain until (in an
interactive shell) the top-level interpreter implicitly sets a
non-zero status and prompts again.