Zsh Mailing List Archive
Messages sorted by:
Re: Aliasing separators (Re: grammar triviality with '&&')
- X-seq: zsh-workers 34662
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Aliasing separators (Re: grammar triviality with '&&')
- Date: Thu, 5 Mar 2015 17:42:40 -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> <150305090720.ZM8441@torch.brasslantern.com> <firstname.lastname@example.org>
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
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
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
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.
Messages sorted by: