Optimizing Your Linux Shell Experience

Are you familiar with huffman encoding? That’s where you pick shorter codes for more frequent letters. Morse code is the same way. Shorter characters are the ones you are most likely to use. [Matheus Richard] had the same idea for optimizing your workflow in the Linux shell. The idea is to measure what commands you use the most and make them shorter.

If you use zsh, it is easy to find out what commands you are using the most. If you use bash, [Matheus] helpfully offers a command to give you a similar result (the original post limits the list to the last entry which we are sure is a typo):

history | awk '{CMD[$2]++;count++;}END { for (a in CMD)print CMD[a] " " CMD[a]/count*100 "% " a;}' | grep -v "./" | column -c3 -s " " -t | sort -nr | nl | head -n10

Once you know the commands you use the most, you can use your shell’s aliasing or scripts to shorten them up. For example, in [Matheus’] case, git was a very common command. This led to aliases:

alias gc="git commit --verbose"
alias gp="git push"
alias gprom="git pull --rebase origin main"

Not only does this save typing, but you lessen your chance for typos (git comit, for example). Another idea is to alias your common errors, for example setting an alias for git as gti.

Small things, but definitely time savers. Be sure to read the rest of the post, as there are a number of other optimization ideas. [Matheus] definitely has a thing for zsh, but there are many other shells out there. Some of them are even evolving towards more modern programming languages.

13 thoughts on “Optimizing Your Linux Shell Experience

  1. For sure, I’ve been using long lists of aliases for over 25 years so I can do lots of nifty command-prompt things quickly and without mistakes. It’s to the point that I have to look at my .bash file to recall the actual commands, haha.

  2. the original post limits the list to the last entry which we are sure is a typo

    What specifically are you referring to? Because if you refer to history 1, this is needed with zsh, by default history only returns the last 10 entries and you have to specify “how far back” you want to go.

    For bash this however not the case..

    1. Bash history seems to only return the last 1000 commands.

      This probably will get mangled by the comment processing markup whatever. But this should reliably get the top 20 commands for bash users:
      $ cat ~/.bash_history | awk ‘{ print $1 }’ | sort | uniq -c | sort -hr | head -20

    2. History of commands in zsh is configurable, both in count and storage consumed.
      I keep the last 20,000 with no difficulty, including timestamps, and
      checkpoint my histories periodically so that I have years of records.

  3. You don’t lessen your chance of significant typos by making every command a 2 letter command.

    Careful what you allow to happen without user interaction.

    (Ignore those that say they would never do anything stupid in an aliased command….)

    1. No, Al is correct.

      This was studied by IBM. They wanted to reduce the number of programmer errors and did a whole bunch of experiments and surveys.

      They found that the number of typos is proportional to the number of characters typed, and it was unrelated to any other consideration such as the intent or meaning of the characters typed. Each programmer had a constant number of typos per 100 lines of code, that number varied by programmer, and didn’t change much over the course of the study.

      C programmers had the same number of typos per line of code as did assembly programmers.

      Their conclusion was that programming languages that were highly expressive – ones that packed a lot of meaning into a few lines – would have fewer typos than less expressive languages.

      This then got taken to extremes for languages like APL and perl, but the theory is sound.

      Reducing the typing you need to do for frequent commands will also reduce your chances of making a typo.

      (I happen to like perl for its expressiveness. I don’t push the envelope beyond human understanding, but the ability to read a file into an array of strings or build a structure on the fly without having to go back and forth between ideating a new value, adding it to the definition, then going back to use it.)

  4. I’m a big fan of aliases, but I tend to create them based on how long the command is, rather than how often I use the command.

    For example, I haven’t aliased git’s push and pull operations (used many times per day), but I’ve got an “fmm” alias to Fetch the latest code from Main and Merge it into my current branch (used maybe once per day, maybe less).

  5. This doesn’t seem like a good idea if you use multiple systems or have to use systems that aren’t yours. Then you either have to set up your aliases and remove them after or type the full command which you might not know as well as you should because you just use your alias. Most commands are short enough that they aren’t that much trouble to type and you can use autocomplete too.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.