Zsh Mailing List Archive
Messages sorted by:
Aliasing separators (Re: grammar triviality with '&&')
- X-seq: zsh-workers 34658
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Aliasing separators (Re: grammar triviality with '&&')
- Date: Thu, 5 Mar 2015 09:07:20 -0800
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <54F33934.email@example.com> <firstname.lastname@example.org> <54F345D3.email@example.com> <D0509295-7DA9-4F18-9E3D-D50C0A756998@larryv.me> <20150302022754.GA7449@xvii.vinc17.org> <CABx2=D8efL3X2tfB+_+VweY2yye6EhaMNbJa3b3jJeVMp=7gaQ@mail.gmail.com> <20150302104619.GC6869@xvii.vinc17.org> <firstname.lastname@example.org> <CAH+w=7YoHjN85hqOZVywOfYGZqvU74vZrbE84Ln+V2HQi-6nSA@mail.gmail.com> <20150304144756.GA27231@ypig.lip.ens-lyon.fr> <150304175112.ZM19818@torch.brasslantern.com> <email@example.com>
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
+Src/zsh:3> true foofalse
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
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
Messages sorted by: