rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Byron Rakitzis <byron@rakitzis.com>
To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu
Subject: Re: New rc snapshot, includes "the equals hack"
Date: Mon, 21 Aug 2000 19:28:01 -0500	[thread overview]
Message-ID: <200008212328.QAA17096@rakitzis.com> (raw)

>  Having read the messages to date and thought about the issue, I think
> that I agree with this. I prefer an rc where the rule I have to remember
> is 'quote ='s or get syntax errors', not '= will gobble the arguments
> on either side of it on a command line into one word' (or whatever the
> exact rule is). And slipups are far more evident and less mysterious
> with the first rule: I get a syntax error, which I can easily fix.

Well, the principle of "free carets" already establishes that there
can be some counterintuitive parsing:

	; ~a
	; a~
	a~ not found
	;

I guess the real problem is that = is an infix operator, and what's more
multiple local assignments are allowed:

	a=foo b=bar cmd

This more than anything bollixed up any attempt to do the Right Thing
with yacc alone when I last puzzled over this (which was, mind you almost
10 years ago!).

And what is the right thing? I guess it's easy to say in English: if '='
does not appear in an assignment it should be subject to free careting.

This would be trivial to do in a recursive-descent parser which could
communicate with the lexer, I'm unsure about how to accomplish it
with yacc.

I think there is enough historical precedent about the use of unquoted
='s in shells that to be forced quote them is a truly annoying bug.

Byron.


             reply	other threads:[~2000-08-22 20:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-22  0:28 Byron Rakitzis [this message]
2000-08-22 23:23 ` Chris Siebenmann
  -- strict thread matches above, loose matches on Subject: below --
2000-08-23  1:03 Byron Rakitzis
2000-08-18 21:14 Bengt Kleberg
2000-08-15 20:25 smd
2000-08-15 14:32 smd
2000-08-15 22:51 ` Smarasderagd
2000-08-17  3:53   ` Decklin Foster
2000-08-21 23:21     ` Chris Siebenmann
2000-08-22 11:51       ` Carlo Strozzi
2000-08-17 10:49   ` Tim Goodwin
2000-08-15  7:28 Byron Rakitzis
2000-08-15  6:41 Byron Rakitzis
2000-08-11 14:01 Tim Goodwin
2000-08-15  2:21 ` Paul Haahr
2000-08-15  4:21 ` Gary Carvell
2000-08-15 14:52 ` Mark K. Gardner

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=200008212328.QAA17096@rakitzis.com \
    --to=byron@rakitzis.com \
    --cc=cks@hawkwind.utcs.toronto.edu \
    --cc=rc@hawkwind.utcs.toronto.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.
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).