Self-reflection on a shell selection

Life is a sequence of choices we make, consciously or semi-automatic way based on intuition. From global strategic ones down to tactical and minuscule ones. Well, philosophy aside.

My Unix user life took its beginning in the '00s. As it frequently happens within a social group of young persons with some level of addiction and excitement around a thing, the participants try to follow the established style or current hype to conform to the group’s culture. Or even bring something new to stand out. The X11 based desktop, as an example, is a separate world with a wide spectrum of possibilities to express yourself. Another example is a Unix shell. It’s not smaller in opportunities, probably it’s even more expressive than I may think.

I started my learning path with Bourne shell and Bash respectively. But from time to time I had a temptation to follow some hype around other modern shiny shells or configurations with distinctive features, presumably better UX, etc. In some way, I managed to stay with Bash. My personal and work environments had solid reasoning. It was not a rare case for me to work with various remote Unix-like machines, and, let’s say, for 99% of cases the Bash was the one I met at the entrance. So, it was an investment with a good ROI to learn and practice Bash only and not to spend time on alternatives. After all, learning alternatives would allow me to do the same but through another tool — it does not sound like a profitable deal. Moreover, the shell scripting field is based on sh/bash as a standard de facto.

Also, through the years I’ve simplified the configuration of my shell and related tools like tmux, to remove visual peculiarities, stay with charsets usable with basic fonts, and so on. Such simplification allows me to have almost the same UI/UX regardless of the runtime environment, whether it’s X11 based, Windows GUI based, macOS GUI based, or the simplest SSH based pseudo-terminal.

Built-in aliases are awesome if carefully crafted

Following the same reasoning, I’ve always strived to get used to the existing interface of a program, and stay away from custom aliasing. Not to trap into such cases when a few keystrokes on your main workstation do the magic, but the same on a remote host makes you feel frustrated — an alias or a shortcut does not work, you have to quickly remember how to do it the normal way, and the whole idea falls apart.

Because of that, I like programs with practical defaults. A good example from my personal experience is Subversion with its builtin aliases like svn co and svn st, which work wherever I go. An older example is vi/Vim editors, where the whole interface is based on a set of carefully thought-out shortcuts.

It was time to make a compromise

After years of Git usage, when most of my old projects have migrated from Subversion to Git, and the latter has become the only VCS tool in fact, doubts have started to roam after another git status or git branch -avv typed for the thousandth time.

My Git experience was not efficient and some compromise had to step in. As a result, I ended up with my set of shell aliases:

alias gs="git status"
alias gd="git diff"
alias gds="git diff --staged"
alias gb="git branch -vv"
alias gr="git remote -v"
alias gf="git fetch"
alias gfa="git fetch --all"
alias gwt="git worktree"

I guess the gs, gd, and gds are my key aliases to mention. And the additional ones were added when it was time to work with submodules a lot:

alias gsm="git submodule"
alias gsmur="git submodule update --recursive"
alias gsmuir="git submodule update --init --recursive"
alias gsmup="git submodule update --remote"
alias gprs="git pull --recurse-submodule"

Later I had to break the "stick to the defaults" deal once more. I guess the intensive work with Kubernetes led many of its users to something like this:

alias k="kubectl"

Also, the early adopters of Docker Compose easily catch the idea of the following alias I have in my belt:

alias fig="docker-compose"

Conclusion

This is a subjective topic with some holy wars around, presumably. Business needs and personal preferences vary. But, if there is no personal opinion formed yet, then this specific reasoning and example can be one of the numerous recommendations that provide a starting point to tailor your own path from.

 
 

Copyright © Igor Ostapenko
(handmade content)

Submit a like