From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7339 invoked by alias); 5 Mar 2015 17:07:27 -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: 34658 Received: (qmail 21501 invoked from network); 5 Mar 2015 17:07:26 -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=CNjQ5Xh20mBedTK5dP7L9/LfqqMZbs97w8fGcBgs6Ic=; b=jTuJKCUM6yXkjpAHgsiRkeCFD5SuBvS6ESQEdgHA0KUz47CMKo8nDiNjIGX60G/TY4 it5kY6O7vTa61FxPsReN3aRdlzprwDuEzrKL+ZmwzCG71PzRzaoVoo1IyIlbFKjVpULM 3b5eLzXxcBDkf66euAauGePk7qTo6hGWyO9SgxinRMQwLPiotS/oZ0IIZXHUTJvVIvPW atgaadJIpyClOvIXAriO6Et+iueENBLEuoQMKqwuHlixebL9+VDrX5AXWJm20cAj1JTW Sv1EUiCRapS44wVHvvO6QFxjvIxhmMetckrz5Ulp2zQVdja2okiwr7biRYDgp6h0UA+e 6qXA== X-Gm-Message-State: ALoCoQnIqCx1qIBazFq83Bk/PWT/eiA2Et2nqM++AORvFT4WS4NqCZIleEbmi1Ljuxf5aVNpXsQ8 X-Received: by 10.202.65.8 with SMTP id o8mr7228064oia.113.1425575244480; Thu, 05 Mar 2015 09:07:24 -0800 (PST) From: Bart Schaefer Message-Id: <150305090720.ZM8441@torch.brasslantern.com> Date: Thu, 5 Mar 2015 09:07:20 -0800 In-Reply-To: <20150305100638.55631238@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: grammar triviality with '&&'" (Mar 5, 10:06am) 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> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Aliasing separators (Re: grammar triviality with '&&') MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Moved to zsh-workers. On Mar 5, 10:06am, Peter Stephenson wrote: } } > Although I see PWS has already made a (broken?) stab at changing this, } > I think that's a documentation omission rather than a code bug. Some } > things intentionally cannot be aliased. } } I don't think that makes sense: there's too much you already can alias. } You can alias reserved words and arbitrary magic sequences like \&, for } example, and consequently already have the power to do as much damage as } you like. Forbidding it in this case would just be providing an } unmemorable list of special cases. There has to be a line somewhere; you can't usefully alias whitespace, for example. And I think this particular case goes over that line. 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 -- separator tokens don't need to be delineated by whitespace, but the intention of aliasing is that it does NOT take place "inside" an unbroken string without whitespace around it. 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.