Re: Bug with continue?

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

> On 28/03/2023 11:17 Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> wrote:
> > On 28/03/2023 10:32 Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
> > I notice this works differently in zsh than in other shells:
> > 
> >   for x in 1 2 3 4; do
> >     continue &&
> >     list="$list$x " &&
> >     echo "x: $x"
> >   done
> >   echo "list: $list"
> > 
> > Why did the statement after `continue` gets evaluated?
> > 
> > The original code tries to do something useful `case "$x" in 1)
> > continue ;; esac &&` but it shouldn't matter.
> > 
> > I tried in bash, ksh, and dash, and all of them continue immediately,
> > except zsh.
> > 
> > That can't be the desired behavior, can it?
> 
> That looks like it probably ought to be regarded as a bug to me, yes ---
> I guess it's been hidden because the test "if this statement successfully
> jumped somewhere completely different then..." isn't spectacularly useful.
> However, it's not logically wrong, either.
> 
> I think we had something a little similar to this recently; it usually
> boils down to something quite simple once you've found it and I'll
> have a look when I've got more time.  (Patch would go to zsh-workers.)

The bug I'm thinking of is zsh-workers/51125, though it looks like I
committed the fix under zsh-workers/51134.  That was about wheter
"! return" should invert the status of the return given it's already
returned by the time that would happen.  This is similar, but looks
like it's not the same.

This one is a little weird as if the immediately next statement is a
print it doesn't get executed.  I'm suspecting some subtlety with handling
retflag.

pws