Re: Parse error (lack thereof) on incomplete loops

[Peter Stephenson <p.stephenson@samsung.com>]

On Thu, 2018-10-04 at 13:34 -0700, Bart Schaefer wrote:
> My problem with it is that it's not consistent.
> 
> set -x
> { while false
> while false
> }
> 
> The shell is now in an infinite loop executing "false".  Can this
> really be intentional?

What's happening here is to do with

while false; do
  print Never executed
done
print $?

This prints 0.  So the body of the last "while false" is actually
irrelevant.

The original expression is parsed as

{
  while {
    false
    while false; do
    done
    }; do
  done
}

which is an infinite loop because of the point above.  Or, in other
words, it's the same as

{
  while false
    true
}

This also used to give a parse error for the same reason.  However,
apart from that there's nothing new --- you can see that even with
NO_SHORT_LOOPS,

while false; true; do print Looping; done

(where that "true" could be a "while false" loop, if you like) has been
an infinite loop since way back when.  The only new feature is that all
the "do ... done" clause has become optional if it's possible to infer
there's nothing there.  That seems to me entirely consistent.

Without a "do" while doesn't know where the expression ends.  That's
fundamental to how SHORT_LOOPS works and why I regard it as so
ill-defined as to be useless in all but the simplest cases.  This new
(accidental) feature is giving it a particularly straightforward way of
telling it where the expression ends.

Anyway, I'm perfectly happy either restoring the parse error or not,
depending on the opinions of people more likely to use or fall foul of
this kind of syntax but I don't think the reason "it's all a bit weird"
is good enough on its own for restoring it.  Short loops *are* weird.

pws