From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13905 invoked by alias); 6 Mar 2015 19:26:37 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34668 Received: (qmail 1767 invoked from network); 6 Mar 2015 19:26:35 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=uOHDCfAMWeOvvbUnyGmt7j2aP5eVvvRV7fvrmF8jdo4=; b=i3MM12I+ClL9/vtg29HmZ94iU7O73coBkno9lms1ciBlnzm5yBtaruX4ML7LYMc8Fb MPnFprOm1Anr+x+zJqX2LXK6u/RwUSW45/8s8cGx8tkGh0nDHXq0QnzVyvcpnRbjD7R1 YlDxgZF0oQhDR00rPddi5pTgX5p9IzK1wty5ZS+5cUhtAwIEJN+4SwuYob0ISvC9+tnW Pdixsj+aI9cwDFXJ5N/sza2UFuFnVMH7lm7QYyhjp5XfVfz1y3ik7+QiQsb2N9wDLYDR qSVD4yL4ythgvZclI5Q5imQxNcHcUqSvyeUE9MSpeCraHN5keZFl5+FXCgu/fgHcvP+2 0wvg== X-Gm-Message-State: ALoCoQn/CHkRiQsn5duZhtsBhJWrofTZStUvaszcVp+IsmmQkSiXiuyXphNLKOTaCgKmu8WUg0sR X-Received: by 10.202.229.141 with SMTP id c135mr11595908oih.44.1425669992253; Fri, 06 Mar 2015 11:26:32 -0800 (PST) From: Bart Schaefer Message-Id: <150306112628.ZM9769@torch.brasslantern.com> Date: Fri, 6 Mar 2015 11:26:28 -0800 In-Reply-To: <20150306094039.3d968c63@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Aliasing separators (Re: grammar triviality with '&&')" (Mar 6, 9:40am) References: <54F33934.2070607@eastlink.ca> <13666281425228233@web7o.yandex.ru> <54F345D3.9010204@eastlink.ca> <20150302022754.GA7449@xvii.vinc17.org> <20150302104619.GC6869@xvii.vinc17.org> <20150302110610.2e2c7e86@pwslap01u.europe.root.pri> <20150304144756.GA27231@ypig.lip.ens-lyon.fr> <150304175112.ZM19818@torch.brasslantern.com> <20150305100638.55631238@pwslap01u.europe.root.pri> <150305090720.ZM8441@torch.brasslantern.com> <20150305174011.0be5a31e@pwslap01u.europe.root.pri> <150305174240.ZM8732@torch.brasslantern.com> <20150306094039.3d968c63@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Aliasing separators (Re: grammar triviality with '&&') MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 6, 9:40am, Peter Stephenson wrote: } Subject: Re: Aliasing separators (Re: grammar triviality with '&&') } } OK, to state my basic position (though it's kind of moot --- as I said I } don't think anybody really needs the change) 1. tokenisation is part of } lexing 2. alias expansion comes between lexing and parsing 3. any } result of lexing is game for alias expansion, unless you make stricter } rules than zsh already has. But this discussion isn't really going } anywhere. Understood, but (prior to 34641) zsh *did* have stricter rules, and (in terms of the lexer, not in terms of explaining to end users) the rule was very simple: only STRING tokens are subject to alias expansion. In practice that means something like "only tokens that can be changed by concatenating with another string using simple lexical pasting, may be aliased." But that isn't a very satisfying way to say it (and it's not 100% true because of "{" being a reserved word). As an aside, using zshlextext isn't really correct either if the real intention is to allow aliasing of tokens. Did you plan to allow the aliasing of the NEWLIN token? Because with 34641, alias $'\n'=... does not work, but alias '\n'=... actually does create an alias for hitting enter at a blank PS1 prompt. The point being that for non-STRING tokens, zshlextext doesn't always represent the actual input string. The other minor point is that this slows down lexical analysis a lot. Many more things are going through checkalias(), including in some cases (as you pointed out) every individual character. Finally it seems wrong that "setopt POSIXALIASES" disallows aliasing of reserved words but (with 34641) still allows aliasing of other special tokens. } On Thu, 5 Mar 2015 17:42:40 -0800 } Bart Schaefer wrote: } > torch% &&bar } > } > I would argue that the "&&" is NOT "in command position" because in the } > normal lexical situation "command position" ENDS just to the left of any } > separator. There's NOTHING in "command position" in that example. } } Well, that's not how the lexer actually works. It's been told it's in } command position and it fetches the next token. So whatever comes at } the start of the line *must* be in command position. This is curiously flipped around from the previous discussion; now you're arguing from the strict lexer POV and I'm talking about what it ought to mean to the end user. The lexer can certainly be (and was, before, though it was not explicitly stated) smart enough to know that any token that arrives at that point with tokstr == NULL is not in fact something that could be a command and therefore shouldn't be treated as one. } Given that, in any case, no one is actually suggesting we change the } lexer to do something different with "&&" I don't think I see the } relevance anyway. "&&" is a token and either expanded as an alias or } not It's relevant to "alias" vs. "alias -g". If && at the start of the line is not in command position, then it doesn't expand unless it has the global-alias flag. Incidentally here is a curious bug that is present both (long, long) before and also after 34641: torch% alias \{='print foo' torch% { this is a test foo this is a test So far so good, now recall from history: torch% { this is a test Back up and delete the space after "{": torch% {this is a test foothis is a test Now recall from history again: torch% { foothis is a test That seems like an oopsie. I'd actually rather the disambiguating space after the brace was inserted when the alias expands instead of pasting up "foothis". But let's figure out whether to undo/redo all or part of 34641 first. -- Barton E. Schaefer