Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Bug (?) with "return" from inside "while"



On Sat, 5 Nov 2016 15:16:09 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> As best I can tell, the exit value of a "while" loop is supposed to
> be the exit value of the last executed statement in the loop-body,
> but the value of $? on entry to the loop body is supposed to be the
> value of the last executed statement in the condition.

Yes, that just got fixed for certain constructs.

> The question is what the exit status should be if the conditional
> includes an explicit "return N".  dash and zsh up to this point
> return the exit status of the loop body, or zero if the loop body
> has never executed.  Bash returns N, which seems more correct.

You'd think so.

> A related question is what happens if the loop is interrupted with
> ^C.  The most recent changes to execwhile() are all about handling
> that (plus making the interrupt possible if the condition or body
> or both are empty).  Is an interrupted condition the same as one
> that returned false (or true in the case of until)?  This somewhat
> obscures what is intended in the case where there is no interrupt.

If it's interrupted, any stack of callers should be interrupted, too.
The status should only be significant when you get back to the top
level, or exit the shell, and this should happen if errflag is et.  Then
it should fix up a suitable status at that opint.  So the key thing
internally is making sure it does get interrupted.

> There's also the question of what $? should be upon entry to the
> condition.  On the first loop it's unchanged from the previous
> command, but on successive loops it's the value from the loop body.
> On the other hand the value of $? on entry to the loop body is the
> value from the condition (always 0 for while, nonzero for until).
> (Patch below doesn't address this at all.)

That's not obviously stupid.  Those are the last commands to have been
executed.  Recently found problems were due to clearing it when it
shouldn't be, rather than leaving it do the last value.

pws



Messages sorted by: Reverse Date, Date, Thread, Author