need contributor / plug-in guidelines on aliases and disabling setting of aliases

[ncolton]

Some good discussion has already happened in #5721 but this is an issue not just limited to the plugin for git.

Some examples:
#4780
#5214
#5288
#5313
#5766
#5774
#5783
#6062
#6601

There needs to be some form of guidance on how to add aliases while being a good citizen, especially since some aliases can be very dangerous and destructive. It would be nice to adopt the added functionality that many plugins provide, but have the option to use, or not use the aliases provided by the plugin.

Similarly, the libraries also exhibit some of this. lib/directories.zsh creates 23 aliases on it's own, lib/misc.zsh creates 2 different aliases for sudo. In comparison, lib/correction.zsh also creates a number of aliases, but they are gated behind an option so I can easily enable or disable them.

I've avoided some plugins because of the sheer number of aliases I'd be "forced" to have from them. For the 23 aliases from lib/directories.zsh I resorted to creating an empty custom/lib/directories.zsh to disable them. I don't consider it to be realistic to have each user have to check every update to see if any new aliases were created, then add an unalias yet_another_alias for every new unwanted alias.

[ncolton]

As an additional note, the aliases should probably be opt-in so they don't just overwhelm new users and you are given a chance to explore them and ideally understand them a little before turning them on.

[Shea690901]

Not only the aliases should be optin but also (un)setopt's...
e.g.: I have alias l=less (added as different alias by lib/directories.zsh) and I don't like setopt autopushd (set by lib/directories.zsh)...

[hoylemd]

The directories aliases are getting in my way a lot. It'd really be nice if I could disable them.

[duhd1993]

This is really needed. I don't want aliases that I don't know where it is defined and how to enable/disable.

[damien]

Ran into this today with aliases defined in lib/directories.zsh. Had to run a ZSH process in debug mode to figure out where aliases were coming from. I have some thoughts on how opt-in aliases could be managed. Here are some thoughts:

Current problems

1. ZSH itself and ZSH plugins define aliases in a global context.
2. Unless specifically coded into ZSH or ZSH plugins, there is no way to opt-out or configure alias definitions
3. A user has no straightforward way of knowing where an alias comes from
4. For aliases offered by plugins that are opt-in, a user has no way of knowing what aliases are available

Proposal

Provide a mechanism within ZSH for registration of aliases. This mechanism would keep track of a mapping of aliases, their recommended labels, and the shell snippets they contain. ZSH could them provide further mechanisms to allow interaction with this alias store to do things like enable, disable, or rename an alias.

In abstract, I think it'd look something like this:

Alias Source	Alias Label	Alias Value	Active	User Label
directories.zsh	lsa	ls -lah	TRUE	NULL
directories.zsh	l	ls -lah	FALSE	NULL
custom/exa.zsh	l	exa -FG	TRUE	NULL
custom/exa.zsh	ll	exa --extended	TRUE	el

This would ideally result in the following behavior:

1. lsa executes ls -lah; the user didn't modify anything and has that alias enabled from directories.zsh
2. l would execute exa -FG; this conflicts with l defined in directories.zsh, but is resolved by the latter alias being inactive/disabled
3. el executes exa --extended ; custom/exa.zsh originally defines the command under the alias ll, but the user has remapped the alias with to a new name, el

Does this sound like overkill? I'd be happy to contribute something like this, but there'd still be open questions about interface and migration paths. Open questions off the top of my head:

1. For any new approach, how do we get existing plugins moved over with a minimum of fuss and work?
2. What would a UI/TUI for this look like?
3. How big a problem is this, really? I know it's hit me and a few other people on this thread. Is this a big enough problem/concern to justify additional complexity this would add to an already large project like oh-my-zsh?

Cheers! 🍻

[rwmitchell]

i'm not a fan of OMZ providing aliases for commands that have been around forever without the user opting in. Having an alias for 'ls' really annoys me, for example.

I've used someone's Extended-LS (els) for a long time, modified it to support colors, commas in the size field, glyphs for file types and hg status; written in C and doesn't require ruby or any other silly add-ons. I have 'ls' defined as a function and apparently zsh using a function or an alias with the same name differs between OS X and linux...linux calls aliases first. Like posters above, spent a long time chasing down why I suddenly had a broken ls on linux and where the alias was getting created.

I love that OMZ brings a lot of zsh tools together from everywhere, but I also like being able to select what I want to use and don't like stuff being forced on me.

[mcornella]

There's a proposal for a way to turn off aliases in #10644. Please have a look and add your feedback. Thanks!

[mcornella]

This was implemented in #11550, see https://github.com/ohmyzsh/ohmyzsh#skip-aliases for how to use it.