From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11419 invoked from network); 4 Apr 2000 21:02:06 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Apr 2000 21:02:06 -0000 Received: (qmail 7083 invoked by alias); 4 Apr 2000 21:01:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10488 Received: (qmail 7076 invoked from network); 4 Apr 2000 21:01:43 -0000 Subject: Re: == ? In-Reply-To: from "[Johan Sundstr_m]" at "Apr 4, 2000 07:00:42 pm" To: "[Johan Sundstr_m]" Date: Tue, 4 Apr 2000 22:01:34 +0100 (BST) CC: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram [Johan Sundstr_m] wrote: >Sounds reasonable. After some digging through zshmisc(1), I'd guess the >situation we're trying to protect from a possible ambiguity is "< word" -- >am I right? Right right. > I may be at a loss here, but I don't quite see where the >problem might arise. Could someone depict an example or two and how to >trigger the problem? cat <123-456>foo zsh treats this as a command line with two words, one of which is a glob pattern that will match "00234foo" and so on. Bourne shell syntax has this meaning the same as the way both zsh and sh interpret cat <123-456 >foo which is a command line with one word and two redirections (input from "123-456", output to "foo"). It's quite common to omit spaces before and after redirection operators. >I noticed them being different (which showed better using cat than echo), >but I failed to understand how the first case tried to operate; to me, it >seemed like a broken effort at <<- or <<<, but then I guess I just didn't >understand what happened, so my guess isn't worth a lot. :-] What actually happens if you type "echo a<1" (before my patch) is that the lexer sees a word "echo", then sees another word that starts with "a". After the "<", it looks for a ">" to finish that glob operator; it gets a newline, which is treated as part of the word, then it asks for more input, still reading that word. Try typing "x>y" as the second input line to complete the word. Completely broken behaviour, nothing to do with here documents. >Either way, I'm not sure I see the impact of this on the case where the >word continues with a > and possibly more pattern matching. After all, >when I want redirection, I don't try my luck at inserting a < or > in >the middle of the current word I'm typing, Quite. The practical rarity of the syntax clash is the only reason that we can get away with that as a glob syntax. The reason for requiring the "-" is to make the clash as small and as simply bounded as possible. > and I haven't found anything in >the man pages supporting that behaviour either. It's not clear on where whitespace is permitted. Whitespace is allowed but not required before and after redirection operators. -zefram