Possible bug: Zsh function does not terminate when ${name:?word} fails

Possible bug: Zsh function does not terminate when ${name:?word} fails

[Ronald Fischer]

(See also for a complete discussion:
http://stackoverflow.com/questions/39463547/zsh-function-does-not-terminate-when-nameword-fails?noredirect=1#comment66276136_39463547)

I have in my .zshrc the following function definition (simplified
example):

function foo {
  local p=${1:?parameter missing}
  echo continue ....
}

Running the function by just typing foo produces, as expected, the
message parameter missing, but it also outputs continue. I had expected
that the function terminates when the :? check fails, but it continues
to run.

I tested this with zsh 5.1.1, but I was informed that this behaviour
also can be reproduced with zsh 5.2

Ronald

Re: Possible bug: Zsh function does not terminate when ${name:?word} fails

[Mikael Magnusson]

On Wed, Sep 14, 2016 at 10:00 AM, Ronald Fischer <ynnor@mm.st> wrote:
> (See also for a complete discussion:
> http://stackoverflow.com/questions/39463547/zsh-function-does-not-terminate-when-nameword-fails?noredirect=1#comment66276136_39463547)
>
> I have in my .zshrc the following function definition (simplified
> example):
>
> function foo {
>   local p=${1:?parameter missing}
>   echo continue ....
> }
>
> Running the function by just typing foo produces, as expected, the
> message parameter missing, but it also outputs continue. I had expected
> that the function terminates when the :? check fails, but it continues
> to run.
>
> I tested this with zsh 5.1.1, but I was informed that this behaviour
> also can be reproduced with zsh 5.2

This seems to be a side effect of the reserved word handling, if you do
disable -r local
then it behaves as expected. Being in a function or not makes no
difference, the same thing happens if you do
local p=${foo:?hello}; echo continue
on the command line.

-- 
Mikael Magnusson

Re: Possible bug: Zsh function does not terminate when ${name:?word} fails

[Peter Stephenson]

On Wed, 14 Sep 2016 10:00:44 +0200
Ronald Fischer <ynnor@mm.st> wrote:
> I have in my .zshrc the following function definition (simplified
> example):
> 
> function foo {
>   local p=${1:?parameter missing}
>   echo continue ....
> }
> 
> Running the function by just typing foo produces, as expected, the
> message parameter missing, but it also outputs continue. I had expected
> that the function terminates when the :? check fails, but it continues
> to run.

Yes, that's a bug.  As documented it should return to the top-level
prompt when interactive --- that means it will abort not just the
function but any surrounding code.  If that's not what you want you
might want to look at the ERR_RETURN option as an alternative.

I have to admit the resetting of error flags in zsh is something I've
never got properly to grips with, but now we have individual bits in the
errflag status variable this is straightforward to fix; most of the
logic we need is already there.  The lack of that until a couple of
years ago may be why this has been the way it has for so long.

pws

diff --git a/Src/subst.c b/Src/subst.c
index 1c2027f..92fde45 100644
--- a/Src/subst.c
+++ b/Src/subst.c
@@ -2922,6 +2922,13 @@ paramsubst(LinkList l, LinkNode n, char **str, int qt, int pf_flags,
                 if (isset(EXECOPT)) {
                     *idend = '\0';
                     zerr("%s: %s", idbeg, *s ? s : "parameter not set");
+                    /*
+                     * In interactive shell we need to return to
+                     * top-level prompt --- don't clear this error
+                     * after handling a command as we do with
+                     * most errors.
+                     */
+                    errflag |= ERRFLAG_HARD;
                     if (!interact) {
                         if (mypid == getpid()) {
                             /*
diff --git a/Src/zsh.h b/Src/zsh.h
index 996bc33..2dc5e7e 100644
--- a/Src/zsh.h
+++ b/Src/zsh.h
@@ -2807,7 +2807,14 @@ enum errflag_bits {
     /*
      * User interrupt.
      */
-    ERRFLAG_INT = 2
+    ERRFLAG_INT = 2,
+    /*
+     * Hard error --- return to top-level prompt in interactive
+     * shell.  In non-interactive shell we'll typically already
+     * have exited.  This is reset by "errflag = 0" in
+     * loop(toplevel = 1, ...).
+     */
+    ERRFLAG_HARD = 4
 };
 
 /***********/
diff --git a/Test/D04parameter.ztst b/Test/D04parameter.ztst
index be6e104..7623051 100644
--- a/Test/D04parameter.ztst
+++ b/Test/D04parameter.ztst
@@ -95,6 +95,20 @@
 ?(eval):1: unset1: exiting1
 ?(eval):2: null1: exiting2
 
+  PROMPT="" $ZTST_testdir/../Src/zsh -fis <<<'
+  unsetopt PROMPT_SP
+  PS2="" PS3="" PS4="" RPS1="" RPS2=""
+  foo() {
+      print ${1:?no arguments given}
+      print not reached
+  }
+  foo
+  print reached
+  '
+0:interactive shell returns to top level on ${...?...} error
+?foo:1: 1: no arguments given
+>reached
+
   print ${set1:+word1} ${set1+word2} ${null1:+word3} ${null1+word4}
   print ${unset1:+word5} ${unset1+word6}
 0:${...:+...}, ${...+...}

Re: Possible bug: Zsh function does not terminate when ${name:?word} fails

[Ronald Fischer]

> This seems to be a side effect of the reserved word handling, if you do
> disable -r local
> then it behaves as expected. 

I don't think this would be a good idea. If I understand correctly, this
would make the variables global (with all consequences from a name
clash). There are other nasty consequences too.

A better workaround is IMO to separate parameter check and assignment,
for instance by

: ${foo:?hello}
local p=$foo # foo is guaranteed to have a value here

Ronald

Re: Possible bug: Zsh function does not terminate when ${name:?word} fails

[Bart Schaefer]

On Sep 14,  1:21pm, Ronald Fischer wrote:
} Subject: Re: Possible bug: Zsh function does not terminate when ${name:?wo
}
} > This seems to be a side effect of the reserved word handling, if you do
} > disable -r local
} > then it behaves as expected. 
} 
} I don't think this would be a good idea.

I think this was being presented as a diagnostic tool, not as a work-
around for real usage.

Re: Possible bug: Zsh function does not terminate when ${name:?word} fails

[Mikael Magnusson]

On Wed, Sep 14, 2016 at 6:20 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Sep 14,  1:21pm, Ronald Fischer wrote:
> } Subject: Re: Possible bug: Zsh function does not terminate when ${name:?wo
> }
> } > This seems to be a side effect of the reserved word handling, if you do
> } > disable -r local
> } > then it behaves as expected.
> }
> } I don't think this would be a good idea.
>
> I think this was being presented as a diagnostic tool, not as a work-
> around for real usage.

Disabling local as a reserved word does not disable the builtin, and
only reverts to the old behavior of not being able to specify arrays'
values on the parameter declaration line.

% a=${foo:?bar}; echo hello
zsh: foo: bar
% local a=${foo:?bar}; echo hello
zsh: foo: bar
hello
% \local a=${foo:?bar}; echo hello
zsh: foo: bar

(the backslash has the same effect of overriding the reserved word handling)

-- 
Mikael Magnusson