A Look At Aliases

One of my favorite things to do is evaluate my personal workflow for ways to improve my work life. While its possible to consider this a matter of increasing productivity, I like to think about it as making my day easier.

And one of the easiest ways to make your life easier is through a good set of bash aliases. In a stressful situation, these can shave crucial time off coming to a resolution.

Personally, I like to choose my own aliases, rather than using ones provided through tools like ohmybash. I do this for multiple reasons: one, I like to choose my own shorthand names, two, I’m meticulous about the organization of aliases, three, too many aliases can become overwhelming and a burden itself. There’s a multitude of categories, but the basic structure looks like: ssh-related, service-related, tooling-related, and project-related.

Let me share a few examples. First, I’ll have a set of SSH related aliases I use to access different machines for different purposes. These are typically named after the machine they connect to and are basic enough to set up:

alias mymachine="ssh user@44.55.66.88 -p22"

Simple enough right? Lets keep going. Next come git related aliases.

alias gs="git status"
alias gaa="git add -A"
alias gc="git commit"
alias pull="git pull"
alias push="git push"

The last few are really nice. git commit is usually followed by a message flag. And because the first part of that command is static, adding the -m flag to the end of the alias works just fine.

But that begs another question: What about commands that contain multiple static parts? Well in comes functions. Simple bash functions work perfectly fine in your ~/.bashrc file. Lets look at an example of an Ansible alias (a configuration management tool):

ansibledeploy() { ansible-playbook "$1" -i inventories/"$2"/hosts --diff ; }

This function(serving as an alias) accepts two arguments: first, the filename of the playbook, and secondly, the second portion of the inventory flag’s file path (allowing for the designation of an Ansible inventory). So in the end, the command looks something like this:

ansibledeploy playbook.yml staging

The one thing about this though: it doesn’t allow for the addition of flags after the command (like the git commit example above). While I’m positive theres a way to accomplish this, I haven’t gone looking for it yet. Instead, since this is a small amount of commands, I applied the same logic to a few different scenarios and came up with this list:

ansibledeploy() { ansible-playbook "$1" -i inventories/"$2"/hosts --diff ; }
ansibledeploystep() { ansible-playbook "$1" -i inventories/"$2"/hosts --diff --step ; }
ansibledeploylimit() { ansible-playbook "$1" -i inventories/"$2"/hosts --diff --limit "$3" ; }
ansibledeploysteplimit() { ansible-playbook "$1" -i inventories/"$2"/hosts --diff --step --limit "$3" ; }

Notice, a few of those use three variables.

I won’t go through my entire list of aliases; I keep a copy here for sharing between devices. But that should provide a good example of how to build out your own personal alias list.

And with that, I’ll end by digressing back to an earlier point. Too many aliases can hinder more than help. Trying to keep up with too many shortcut commands, especially ones that aren’t used often, can be overwhelming. Its best to keep the list succinct and only add to it when you find yourself typing the same long command over and over.