From: <hzoli@VNET.IBM.COM> (Zoltan T. Hidvegi)
To: schaefer@nbn.com
Cc: <hzoli@VNET.IBM.COM>, zsh-workers@math.gatech.edu
Subject: Re: Short loops?
Date: Wed, 26 Feb 1997 14:27:36 -0500 (EST) [thread overview]
Message-ID: <9702261927.AA16863@lotto.fishkill.ibm.com> (raw)
In-Reply-To: <970226110945.ZM16640@candle.brasslantern.com> from Bart Schaefer at "Feb 26, 97 11:09:45 am"
Bart Schaefer wrote:
> 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).
Then the /bin/sh manual is wrong. if (true) then (echo foo) fi works fine
in sh. Of course any corrections to the manual are welcome. The manual
now contains a more or less full formal description of the grammar, but I
agree, that it may be hard to interpret it correctly. In general, it is
not easy to describe the exact grammar of the shell in such a way that it
is easy to understand for the human readers. Note that ksh has the same
problems here as zsh. In sh/ksh the question is when is it possible to
omit the semicolon/newline before `then'. In zsh the brace syntax
complicates this a bit, but it is really the same problem. If the
newline/semicolon can be omitted in a while LIST do statement then the
while LIST { ... } syntax will work as well.
> > 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 }'.
If you interpret LIST as the longest string which is synactically a list
than it is correct. In while true ; { echo foo } the longest possible list
is true ; { echo foo }. Zsh just parses the list as long as it can, and
when the list parses sees something that cannot continue a list it returns.
>
> 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.
Yes, but that would make the manual quite verbose repeating the same thing
many times.
> > 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
} is a reserved word, and it should be recognized only in command position.
But it is recognized in other places as well.
> 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.
{ cannot mean command grouping in echo { ... } just line echo ( ... ) does
not do that. The later is a syntax error in sh. And I think it would be
even more confusing if echo } works but it stops working after you put it
into a while loop using { ... }.
Zoltan
next prev parent reply other threads:[~1997-02-26 19:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-02-26 2:13 Bart Schaefer
1997-02-26 16:10 ` Zoltan T. Hidvegi
1997-02-26 17:11 ` Bart Schaefer
1997-02-26 17:26 ` Zoltan T. Hidvegi
1997-02-26 19:09 ` Bart Schaefer
1997-02-26 19:27 ` Zoltan T. Hidvegi [this message]
1997-02-26 21:14 ` Bart Schaefer
1997-02-27 9:32 ` Peter Stephenson
1997-02-27 15:06 ` Zoltan T. Hidvegi
1997-02-27 18:16 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9702261927.AA16863@lotto.fishkill.ibm.com \
--to=hzoli@vnet.ibm.com \
--cc=schaefer@nbn.com \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).