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

[Bart Schaefer <schaefer@brasslantern.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     
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.