From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17588 invoked by alias); 6 Mar 2015 01:42:46 -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: 34662 Received: (qmail 4325 invoked from network); 6 Mar 2015 01:42:45 -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=0kcjNVu9ip5AZLGwI/BPTynGLiRALNhZlQHiTyzWp3o=; b=a52s6jqgdfWMP7RYmdS0sBscD0rQ7Z+wrRbc8gPBgQskFxc66Pf+JVSgdF8z/d+6q+ NGfBYX0G3B6liK8W+Hift632AQWZB+yM8gTAFfddTQtXQprTRJux4YO85J788zNWaXm9 oWyGL55sq4qzpFkRe/fFRiO2dFpPUgLdT2UPRSs2KkfXG+tWryiCMB9fw/UNt/dlWysb rUFCGUGoiLOjIqLIogTHLlID+OxJf6b5lUt9G0lv/16YE3H+rnb61saiMfLtI+bEBbEV pvXiK5XiWF7S4HFNxHwwDaotdJyfGOQE+boFYQ5JSpILmQmKpNuACB2M6KtTvTFmw5Pn a25A== X-Gm-Message-State: ALoCoQkkZ7UdidvH8bFWgB1jcOGFkoJiMNbXBdflLrBycrpw9oPax4FFmDWu8xSwXDgB98PEokst X-Received: by 10.182.98.164 with SMTP id ej4mr9459841obb.0.1425606163369; Thu, 05 Mar 2015 17:42:43 -0800 (PST) From: Bart Schaefer Message-Id: <150305174240.ZM8732@torch.brasslantern.com> Date: Thu, 5 Mar 2015 17:42:40 -0800 In-Reply-To: <20150305174011.0be5a31e@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Aliasing separators (Re: grammar triviality with '&&')" (Mar 5, 5:40pm) 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> 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 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.