From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11058 invoked by alias); 5 Mar 2015 17:40: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: 34660 Received: (qmail 8659 invoked from network); 5 Mar 2015 17:40:25 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-b7f126d000001e9a-6b-54f89475adb0 Date: Thu, 05 Mar 2015 17:40:11 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Aliasing separators (Re: grammar triviality with '&&') Message-id: <20150305174011.0be5a31e@pwslap01u.europe.root.pri> In-reply-to: <150305090720.ZM8441@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> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsVy+t/xq7qlU36EGFx4JGhxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4MtY0T2AruMpdceLQRaYGxhmcXYwcHBICJhL/5xl1MXICmWIS F+6tZ+ti5OIQEljKKHF+zjUmkISQwBImiff/QiES2xgltn99yQiSYBFQlXix4Cs7iM0mYCgx ddNssLiIgLjE2bXnWUBsYQFniWNzTjOD2LwC9hKr246C1XMKWEqc3vKOBWLofxaJX18+s4Ek +AX0Ja7+/cQEcZK9xMwrZxghmgUlfky+BzaUWUBLYvO2JlYIW15i85q3zBCXqkvcuLubfQKj 0CwkLbOQtMxC0rKAkXkVo2hqaXJBcVJ6rqFecWJucWleul5yfu4mRkjQftnBuPiY1SFGAQ5G JR7egqRvIUKsiWXFlbmHGCU4mJVEeA+2/AgR4k1JrKxKLcqPLyrNSS0+xMjEwSnVwBj/qkhZ n0/N7Jz73tAdXWVar92+N0lvym17U3Wo1v39mfq9T8qi5TRjWu3ORW365/Xvncw5CRaendys zL/+OkVxqwpmmb3oUEh9KyhWM+35rXPWYZN5zb3Tmb5e4jnNaRF7R/9+vovQM7578yMTGldz xMu/MiiaI6/l3LDMMc9k0ntxztIUJZbijERDLeai4kQAJ9CnfTgCAAA= On Thu, 5 Mar 2015 09:07:20 -0800 Bart Schaefer wrote: > Consider, with this patch in place: > > torch% alias -g '&&'=foo > torch% set -x > torch% true&&false > +Src/zsh:3> true foofalse > torch% &&bar > +Src/zsh:4> foobar > zsh: command not found: foobar > > That's CERTAINLY not the intended behavior I would tend to agree with that, but that's largely because I have no idea what the intended behaviour would be. It doesn't surprise me you can get gobbledygook if you alias tokens to something with a different behaviour. You get gobbledygook of a different kind if you alias reserved words to something with a different behaviour. ('alias -g' has always been a disaster waiting to happen, but I think the basic feature is there without that.) > 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. 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). alias -g '*=*; print nonexistent-file' ls * pws