Aliases that ignore "noaliases"

Aliases that ignore "noaliases"

[Bart Schaefer]

There are some cases where it would be nice to be able to declare an
alias that "always works".  The most obvious recent example would be
  alias nameref='typeset -n'
but also some hackiness in zsh/param/private could be avoided with
  alias private='local -P'

This is important when the alias invokes a keyword rather than a builtin, e.g.
  function private { local -P "$@" }
doesn't parse its argument list the same way.  There are some other
instances where an internally-defined alias that (in particular)
survives "autoload -U" might be useful.

Any thoughts?

Re: Aliases that ignore "noaliases"

[Stephane Chazelas]

2024-04-01 12:59:09 -0700, Bart Schaefer:
> There are some cases where it would be nice to be able to declare an
> alias that "always works".  The most obvious recent example would be
>   alias nameref='typeset -n'

For the record, ksh used to have a number of builtin aliases,
but they were causing all sort of problems including breaking
POSIX compliance as things like

suspend() { ...; }

for instance would fail (as suspend used to be defined as a
suspend='kill -s STOP $$' (yes, with the missing quotes around
$$ (!), see https://github.com/att/ast/issues/10)

So they were eventually changed to being separate builtins (on
my request IIRC, though I can't find the bug report any
longer).

TLDR, I think zsh should avoid having builtin aliases.

-- 
Stephane

Re: Aliases that ignore "noaliases"

[Stephane Chazelas]

2024-04-01 21:18:41 +0100, Stephane Chazelas:
[...]
> So they were eventually changed to being separate builtins (on
> my request IIRC, though I can't find the bug report any
> longer).
[...]

Ah. I think that's https://github.com/att/ast/issues/16

-- 
Stephane

Re: Aliases that ignore "noaliases"

[Bart Schaefer]

On Mon, Apr 1, 2024 at 1:18 PM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> TLDR, I think zsh should avoid having builtin aliases.

In the cases I'm thinking of, it doesn't really have to behave like an
alias in the sense of lex-time textual replacement.  For builtins, we
already have a number of them that invoke the same C function
underneath, with different lists of allowed and default options
handled by the "front end" for builtintab entries.  Something similar
for reserved words would go a long way.  Sort of the way "zle -C" uses
a builtin widget to define how a user-defined one should behave.

The "suspend" example from ksh is not particularly apt here because
I'm interested in defining syntax rather than (re-)implementing
commands, so naming would have to be approached just as carefully as
with any new reserved word.