From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11719 invoked by alias); 6 Mar 2015 04:13:44 -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: 34663 Received: (qmail 2358 invoked from network); 6 Mar 2015 04:13:32 -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.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xCW59I/uLrUdoZq0d988o5qOZzRF/hsMS/KHb2IjEhI=; b=aHXeUPNlcGF17gZWyV822+qAgSkFoRqpwqbhFL3ebqfJDECJs5lPahW56bRlWcMHwi eXJERGKDp3PbRciOFIo0QQqfOOa7nVYHUsC/0YHf/3hf69o2H6nKNMD0MDWnTUtGCNer o9fdYnX7ILMcysMZ4ZuMyZNVyKQluq358851gkhTV4pGABxOlIpKsgDlYsjRbvlFsGqP f0XdcnPqZk/qkdKsjnm2Q5b33lGzswQ5rSsjHFHByuaD5M1ssrIvQVf+Z4Oyc9V+/BfH sAtCBTtPpChksgSSYlOeIVUnDPvj6UPei1chTEG4gjOKr3I0DxE8urCP3yLy/wkqMuJE Mrhw== MIME-Version: 1.0 X-Received: by 10.50.79.161 with SMTP id k1mr25212404igx.14.1425615208371; Thu, 05 Mar 2015 20:13:28 -0800 (PST) In-Reply-To: <150305174240.ZM8732@torch.brasslantern.com> 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> Date: Fri, 6 Mar 2015 05:13:28 +0100 Message-ID: Subject: Re: Aliasing separators (Re: grammar triviality with '&&') From: Mikael Magnusson To: Bart Schaefer Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On Fri, Mar 6, 2015 at 2:42 AM, Bart Schaefer wrote: > On Mar 5, 5:40pm, Peter Stephenson wrote: > } > } Personally, I don't see why allowing someone to alias \& but not && > } is logical; either you give users enough rope to hang themselves (and we > } do), or you limit it to non-metacharacters (and we don't). > > It has nothing to do with metacharacters and everything to do with tokens. > > "*" is not intrinsically a token; it's only a token when delimited by > whitespace or other tokens. Similarly "\&" is not intrinsically a token. > If you write "**" it becomes a different thing and any alias for "*" no > longer applies. > > But (unless quoted, when aliasing doesn't apply anyway) "&&" always is > a token; further it's in the class of tokens that separate other parts > of the lexical space into tokens. Allowing separators to be aliased > doesn't just change the outcome of a parse (in the way that, say, an > alias for "fi" would), it changes the rules for constructing other > aliasable tokens. > > Furthermore, ignoring "alias -g" issues which I agree are an entirely > smellier kettle of fish, it changes the definition of "in command > position". With input like > > 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. > > Either "&&" is a separator token and should act like one, or it isn't > and in that example the alias for "&&bar" should be looked up instead. > > } > Aliasing only of STRING tokens is exactly the right thing and this > } > change is simply wrong. The doc only says "before parsing" as a > } > shorthand instead of a long explaination about how the alias is > } > replaced and then parsed all over again. > } > } If you can produce an alternative patch describing the previous position > } properly, go ahead. I don't think anyone is actually screaming to use > } this change. > > I'll think about a documation patch if that's what you mean. You could argue that the documentation is already right, it uses "before parsing", and && is interpreted in the "lexing" stage, right? However, I don't think users can know that... :) -- Mikael Magnusson