From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from proxy2.ba.best.com ([206.184.139.14]) by hawkwind.utcs.utoronto.ca with SMTP id <44193>; Tue, 22 Aug 2000 15:13:41 -0500 Received: from rakitzis.com ([207.20.242.213]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id QAA00596; Mon, 21 Aug 2000 16:28:40 -0700 (PDT) Received: (from byron@localhost) by rakitzis.com (8.9.3/8.9.3) id QAA17096; Mon, 21 Aug 2000 16:28:01 -0700 Date: Mon, 21 Aug 2000 19:28:01 -0500 From: Byron Rakitzis Message-Id: <200008212328.QAA17096@rakitzis.com> To: cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu Subject: Re: New rc snapshot, includes "the equals hack" > 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.