Re: Short loops?

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Feb 26, 12:26pm,  (Zoltan T. Hidvegi) wrote:
> Subject: Re: Short loops?
>
> Bart Schaefer wrote:
> > The doc ought to get changed, then.  The two entries for `while' (and
> > similarly for all the "short" variants) read:
> >
> > `while LIST do LIST done'
> > `while LIST { LIST }'
> >
> > The first and second uses of LIST both require either a newline or a
> > trailing semicolon; the fourth use of LIST may have a newline or a
> > semicolon or not, without affecting the result; and the third use
> > requires not only that there NOT be a newline or semicolon, but also
> > that the list ends with a [[ ]] (( )) ( ) or { } construct.
> 
> No.  No one of the above four LIST require any trailing semicolons or
> newlines.  As decribed in the manual, reserved words like do, done, { are
> only recognized in command position.  [....]  Words are
> in command position after a newline or a semicolon or after )) or ]] or
> after do, then, {, } etc.

Which just means that `do' must be *preceded* by a newline or semicolon
or whatever.  Whether it's the list that requires it or the reserved word
that requires it, the effect is the same and the info's syntax summary is
misleading.  The /bin/sh manual can get away with `while LIST do LIST done'
because in /bin/sh the semicolon or newline at the end of a LIST is never
optional (the definition of LIST *includes* the trailing separator in the
/bin/sh manuals).

Just because there's an explanation somewhere else that says that `do' is
only recognized in command position, doesn't mean the manual can get away
with being sloppy in the syntax summary.  It's OK if you want to use LIST
the way that it is used in `while LIST do LIST done', but in that case:

> Zsh has to know that { is not a simple argument
> to a command, but a reserved word.

That's not a sufficient explanation either!  It has to be not just a
reserved word, but a reserved word in a spot where that particular word
doesn't have an alternate meaning -- which means after )) or ]] or ) or },
but NOT after semicolon or newline.  Which is *not the same* as the rule
for where `do' can appear, which IMHO should mean that the syntax summary
should NOT be written `while LIST { LIST }'.

The doc could define a CLOSED construct to be any of (( )) [[ ]] ( ) { },
and define a CLOSEDLIST to be a LIST ending with a CLOSED but that is NOT
followed by the optional separator.  Then it could say:

`if CLOSEDLIST { LIST } [ elif CLOSEDLIST { LIST } ] ... [ else { LIST } ]'
`if CLOSEDLIST SUBLIST'
`while CLOSEDLIST { LIST }'
`until CLOSEDLIST { LIST }'

And then I'd be happy.

> The { echo } case works and seems to be
> an exception to this rule but is really a pathologic special case handled
> explicitely in lex.c and it only works if ignorebraces is not set.

I don't know what you're talking about here at all, I fear.  An exception
to which rule?  `}' is recognized *everywhere* when ignorebraces is not
set.  Which seems bizarre to me anyway -- if `{' is not recognized every-
where, then `}' ought to be recognized only when an unmatched reserved `{'
has preceded it.  One more state flag in the lexer could fix that.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern