Re: Aliasing separators (Re: grammar triviality with '&&')

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Thu, 5 Mar 2015 09:07:20 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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