DEV Community

The case against aliases

Ben Sinclair on September 03, 2018

A quick glance at the timeline here will show you that shell aliases are a popular topic. Still popular but to a lesser extent are shell functions,...

Read full post

rhymes • Sep 3 '18

All valid points. The main reason why people resort to aliases is how unintuitive git command line interface is. For example I have an alias called git unstage because git reset HEAD -- doesn't actually explain anything at all to me, no matter how many times I look at it. I did always end up googling "how to unstage files" or "how to undo last commit" in the past.

Same goes for "git cherry", the documentation for cherry is Find commits yet to be applied to upstream. They could have called it "git whatever", it speaks to me as little as the word cherry does.

Some aliases are also to shortcut long commands, like git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short.

I agree that you can go overboard with aliases, but I still think there's value in having them

Frank Dana • Sep 3 '18

It's worth noting, also, that git aliases are (or should be) aliased within git, as it adds a lot of nice features:

$ git alias
unstage = reset HEAD --

$ git unstage --help # or
$ git help unstage
'unstage' is aliased to 'reset HEAD --'

$ git unstag
git: 'unstag' is not a git command. See 'git --help'.

The most similar command is
    unstage

That's a lot less terribad than wrapping the same thing in a shell alias or function. Shell aliases for git commands are especially dumb because you're both circumventing many of git's better features, and creating something that's susceptible to all of the issues raised here.

(It's almost as if, knowing their command structure might be... let's say "less than intuitive", the git developers at least decided to include good tools for mitigating that problem.)

Peter Benjamin (they/them) • May 25 '22 • Edited

I have also seen some really long/complex-looking git aliases that are really hard to follow, like:

[alias]
  foo = !"f() { some; really && long | function onliner || with lots of $(sed) && awk '{print $1}' && then call --it at 'the' end ; } ; f"

For these cases, I would recommend creating an executable script placed somewhere in your $PATH named git-foo and git will expose this as a subcommand, like $ git foo. Just like git-extras.

Frank Dana • May 25 '22

Agreed, as an alias abuse that's just obnoxious.

Frank Dana • Sep 5 '18

Actually I guess git alias is part of git-extras, not core git. I guess I never noticed before, since it's just sort of always been there.

Max Cerrina • Sep 3 '18

I am so-so on aliases; I think they make a lot of sense for stuff like git unstage -- ie, taking something and adding a name and meaning that is clearer. Sort of like how if there is a function from an API I am using all the time whose name I find confusing/unclear, I will just make a tiny wrapper function with a name that makes sense, etc. Stuff like gcma to me is sort of like taking document.getElementById and shadowing it to document.gebi

rhymes • Sep 3 '18

Yeah, I try not to alias git commands to acronyms, it makes my life harder.

Alain Van Hout • Sep 3 '18 • Edited

That's a reasonable argument, and used like that it's definitely a beneficial approach. The aliases that most people mention, however, seem to be minimalistic acronyms, which suggests character reduction as the primary goal.

Ben Halpern • Sep 3 '18

My approach to this kind of issue is to sort of "proceed with caution". Like, if you choose to use aliases do so while also being aware of the issues you are describing. Same reason you shouldn't go scuba diving without a pretty decent understanding of how your equipment works (and why it works the way it does). Any time things don't go perfectly to plan, you'll be glad you know the why and how.

Same goes for lots of abstractions. You don't need textbook knowledge of the implementation, but much of what you describe is present across most of software development.

Andrew Udvare • Sep 4 '18

I have a lot of aliases and functions. I have a script that generates them based on the system in question so I can avoid runtime checks of whether the necessary applications are present. Most of my aliases come from this script. The only drawback is I have to remember to run this script and source my aliases again once in a while.

The script has a list of 'simple aliases', where this list of tuples has the required application, the name of the alias, and the actual command:

simple_aliases = (('jhead', 'strip-exif', 'jhead -purejpg'),)

then it checks for the binary in PATH and adds the alias if it finds it.

I do not yet generate the functions output but I probably will soon, based on the dependencies.

Nowadays I prefer functions unless the alias is very simple like alias la='ls -la' or something I really don't feel like remembering: alias ltr='-l --sort=time -r.

The problem may be that completions are generally not available in Bash by default, and I know I find them invaluable, and I write my own quite a bit.

andriy melnyk ╔╬╚╗╠ ╠╣╔╦╣╚╗╔╬╗ • Sep 5 '18

Great! I also rely on history and filter (do not capture) ls and some often used commands to make it shorter

yucer • Sep 3 '18 • Edited

Actually, I did start using them to avoid remembering some Linux commands that did require a lot of parameters and that I had to use seldom. For example: removing my old kernels to free up boot space. I did note that the linux community usually implement new commands or apps for those cases.

With the time, I did start to use them in the commands that I have to type frequently.

Later, I have grouped many of them, and automated all the development task that I do on a daily basis:

pull the upstream changes for all my repositories
rebase my local branches
calling commands from my docker containers
listing my local development databases
taking the snapshopt of one database in the current state (that allows to reproduce the error)
restoring the database to the snapshot state

... and many more

The generated aliases are loaded by my .bash_aliases and their names sometimes are dynamically build according to some parameters (e.g.: the name of the active containers that have the programs they call). With a selected naming convention (with '_') the auto-completion avoids me to type a lot.

At the end, I have use metadata from the different projects that we have, and used a template system to generate the development environment with all the alias prepared.

Some of my workmates use it, they replicate the dev configuration with just few commands, even in new workstations. They also give me feed back, and I try to improve it. I encourage them to improve it also.

I like it because the scripts also installs all the dependencies or generate the docker-compose.yml with all the needed stuff.

Many of my workmates don't like it, because they think they will forget how to use the original commands. I am also afraid of that :-D

But Actually, as soon as possible I will try the dodo commands because I think it seems to be the correct solution for that.

Ben Sinclair • Sep 4 '18

I have a few aliases and one- or two-line scripts that I use for repetitive tasks every day, but the way I most often work is to group them together in one line, for instance to pull my config files, I run:

(cd ~/.dotfiles && git checkout master && git pull origin master && ./install.sh)

since it's in a subshell (the parentheses) it doesn't leave me in a different directory when it's finished and since it uses && throughout it doesn't do anything unless the previous command succeeded. I call this up by doing <ctrl-r>dotf<cr> and rely on it being in my shell history rather than making it an alias.

Sean Henderson • Sep 3 '18

Excellent points! Nice write up.

Regarding audit trails and recusion, that's mainly why I transitioned to fish shell abbreviations instead of regular aliases. It's basically more like a text expansion than actually changing the meaning of a set of characters.

Regarding predictability in portability, I try to only use mnemonic patterns with the first letter of each word. For example, I run gaaand in my head say git add --all as I type. This keeps them quite predictable, and on the rare occasion that I don't have my aliases the command is still in muscle / mental memory in a weird kind of way.

That being said, if I didn't have nerve damage in my hands that slows down my typing, I would probably be use them a lot less for many of the reasons stated above.

Ghost • Sep 4 '18 • Edited

Great article. I have been bitten by aliases more than once.

I remember pulling my hair out over a failing mount command for several hours on a collocated server where a sys admin had aliases the mount command. I tried everything to get my USB drive to mount to no avail.

Finally I tried type mount and learned that mount was aliased. :mad:

The alias caused all my args and options to be misinterpreted by the system and I kept getting unexplainable usage errors.

This experience alone caused me to question aliases as a good practice to avoid typing long options.

I personally create mini shell scripts when I find something repetitive and give the shell script a clever unique name to avoid this nonsense.

Michael Hoffmann • Sep 4 '18

I also wanted to write an article like this after I same the many git alias articles on dev.to 😜

As I started as a developer I also used a lot of aliases. Nowadays, I don't use them anymore for these reasons:

If you want to help a colleague on another computer you often do not have your aliases and maybe don't remember the code behind your alias
Using autocompletion is nearly as fast as using an alias

Thomas H Jones II • Sep 6 '18

Due to the nature of my work (primarily writing deployment-automation for a number of different customers) I work across a lot of (typically short-lived) systems in a given period of time. Relying on aliases is pretty much a non-starter for me. Yeah, I could ship around alias files, but, ultimately, it's all a hassle. Given that I've been using many of my tools for a very long time, aliases typically don't save me enough effort or time to be worth the hassle of shipping me-standard aliases (or encountering a system I couldn't ship to).

andriy melnyk ╔╬╚╗╠ ╠╣╔╦╣╚╗╔╬╗ • Sep 5 '18

There is a good rule: type whatever you want in your terminal, but use only standard commands and long versions of key names in your scripts.

Following this rule you will both save typing and don't forget the basics. + sharing your commands with others won't be painful for both sides

Gregor Gonzalez • Sep 5 '18

I try to not customize any of my tools, neither ides, because I get used to it and then when I change of machine (borrowed, workpc, homepc, servers) I get stuck. Yes you can import or reconfigure but in an emergency you don't have time.

It's really good idea to use aliases for long and complicated commands. Some are unnecessary "commit" for "com" seriously? It's commit difficult? How many commits we do to need that?

I always carry a txt with large commands, for ssh cli, etc.

Greg Bodnar • Sep 4 '18

I've been tripped up by scripts that have been given to me with local functions and aliases applied. That's my primary reason for being explicit, even at the expense of extra typing.