Huffshell: You probably type too much.

While I'm not sold on this particular concept, it does highlight a feature of modern Unices which bears pointing out: the command-line environment isn't some dreadful primitive thing that should only be relied on as a last resort.<p>Rather, it's the evolutionary end-point of some 40+ years of continuous improvement in issuing and processing text-based information streams (both commands and outputs), in a very powerful, highly flexible, extremely adaptable manner.<p>The age of "Oh, Linux, that's like DOS" are far beyond us. But it bears pointing out that this is much like comparing a pogo stick to an F-22 / Boeing 777 / Mercedes E-class. Yeah, the both get you places. How, how much, at what speed, and in what style ... differ.

I've actually been thinking about how I'd like this for all my typing, but it's difficult to imagine how to do it.<p>One trick I've learned, if you want to make sure you get the benefit of this sort of approach, is to ensure that the new alias is not just possible, but mandatory. If you map "git commit" to something, you should make it no longer possible to type "git commit" instead of your new alias, and doing so should pop up the correction. This can also be used to move keys around; turn your Caps Lock into <i>a</i> Control key, you'll never use it, but if you unmap the left Control key at the same time, you'll find you've adjusted in about 5 uncomfortable minutes. It's fast enough to be worth experimenting with.

Hmm. I think my history is a very poor measure of the typing I do. It's the rare command I type that doesn't benefit substantially from tab completion and/or modification of earlier commands.

If you have to do it once, fine. Some work needs to be done.<p>If you have to do it twice, think it over a bit.<p>If you have to do it a third time, automate it.<p>I am lazy enough that I have aliases setup to change to directories I frequently use. I know people who have gone far beyond anything I have done and looking over their shoulder when they are at the shell will show a highly custom environment with dozens of custom scripts that automate all sorts of multi-step commands.<p>I even know a few people who have used most of the alphabet to create single letter scripts. That is efficient!

I fail to see why this is "too much". Pragmatically, for a competent typist, all of these duplicate commands add up to a grand total of what, like 2 minutes a month? You will easily spend a few months of savings performing the analysis and crafting the aliases.<p>Not that I'm against aliases - even minor time savers are indeed worth it - I just wouldn't call it "too much". I bet that a lot of people wouldn't care that much.

The biggest issue I've had when attempting to customise my shell is the same issue I've had while working with my custom vim setup and that is the issue of a different machine.<p>When I log into a new machine I still need to be able to find my way around, I still need to be able to edit files, I still need to be able to run various different commands. These can even be completely different shells or different versions of vi (nvi on FBSD for example, vim without python support on another system and so on).<p>Yes, my workstation has my vim customisations, but it only has the bare needed ones the rest are stock. Even on a vim without any of the scripts I have I would be proficient and I wouldn't miss a beat. Same thing for the shell, typing commands in full means I don't have to worry about muscle memory.<p>ll for example for ls -la is nice and all, but it isn't available on most of the machines I administer so I end up typing out ls -la anyway. That has become muscle memory for me now, and I am not worried about trying to change that.

Does this include the times where the user presses the 'Up' arrow key to retype a previous command?<p>I think that would skew the results a bit if so.

I find that using good aliases for common git command is quite useful. Here are my gitconfig to show some examples. <a href="https://github.com/alexcp/gitconfig/blob/master/.gitconfig" rel="nofollow">https://github.com/alexcp/gitconfig/blob/master/.gitconfig</a>

Using git commit -m is a guaranteed way to write useless and ill-formatted commit messages.

On a similar note, I like to periodically clean out my shell history by dropping commands less than a certain Levenshtein edit distance from earlier commands[1]. Looking at the removed lines would probably produce further ideas for optimizing commands; I'll have to try it next time.<p>[1] rudimentary script: <a href="https://github.com/decklin/bin/blob/master/hprune" rel="nofollow">https://github.com/decklin/bin/blob/master/hprune</a> (haven't bothered to add real option parsing or make it efficient; for shell histories of thousands of lines you probably want to up the search depth to something in the hundreds)

Interesting analysis, once I got it to work. (I have my zsh configured to put history in ~/.zsh_cache/history, not one of the default files. I don't use oh-my-zsh, either.)<p>If I get to the point where I want to play with this, I'll probably fork it and propose some changes back. It also strongly suggests that I should blow away my history because there's some unusual values reported because of my work.

I was inspired by this to share the rebuild alias I've finally come up with:<p><pre><code> sf = tcstop &#38;&#38; mvp stretch-base,stretch-app &#38;&#38; tcs tcstop = ~/tomcat6/bin/catalina.sh stop mvp = mvn package -projects tcs = cl &#38;&#38; tcstart &#38;&#38; sti cl = cleard; cleari; cleare; cleart cleard = find /cygdrive/c/var/log/tomcat6/*.debug -exec truncate -s 0 {} \; cleari = find /cygdrive/c/var/log/tomcat6/*.info -exec truncate -s 0 {} \; cleare = find /cygdrive/c/var/log/tomcat6/*.err -exec truncate -s 0 {} \; cleart = find /home/sthomas/tomcat6/logs/catalina.out -exec truncate -s 0 {} \; tcstart = ~/tomcat6/bin/catalina.sh start sti = tail -f /cygdrive/c/var/log/tomcat6/*.info ~/tomcat6/logs/catalina.out</code></pre>

Also see an old article of mine titled "Working with git? These aliases will save you hours!":<p><a href="http://www.catonmat.net/blog/git-aliases/" rel="nofollow">http://www.catonmat.net/blog/git-aliases/</a>

Is typing git commit over and over again really so terrible? It's pretty much muscle memory anyways.<p>Personally, I like to leave my setup as stock as possible, so I can still be productive regardless of whose computer I happen to be using.

For improving your git-command-related efficiency, you could always use the excellent git-sh by Ryan Tomayko (CTO of GitHub): <a href="https://github.com/rtomayko/git-sh" rel="nofollow">https://github.com/rtomayko/git-sh</a>

For a bare-bones approach, this shell command would also do the trick.<p>cut -d\ -f1 ~/.bash_history | sort | uniq -c | sort -rn | head<p>(Note: There should be two spaces after the -d\ .)

I keep forgetting that bash has tab completion. I only found out when I got fish.