Huffshell: You probably type too much.

by socmoth • 14 years ago

119 54 14 years ago

AlexCP• 14 years ago

I find that using good aliases for common git command is quite useful. Here are my gitconfig to show some examples. https://github.com/alexcp/gitconfig/blob/master/.gitconfig

JustinSeriously• 14 years ago

For a bare-bones approach, this shell command would also do the trick.

cut -d\ -f1 ~/.bash_history | sort | uniq -c | sort -rn | head

(Note: There should be two spaces after the -d\ .)

socmoth3• 14 years ago

(disclaimer: this is my link/blog/software)

If that doesn't work for you, this might:

history 1 | awk '{print $2}' | awk 'BEGIN {FS="|"}{print $1}' | sort | uniq -c | sort -n | tail | sort -nr

What that doesn't give you is the command tree, for example "git commit" vs "git checkout". It just does "git".

[edit, added gem link] The gem is here https://github.com/paulmars/huffshell

psykotic• 14 years ago

Generating the word tree is short and simple, though. It's also useful as a standalone Unix utility. Here's my one-minute hack:

    import sys
    import collections

    tree = lambda: collections.defaultdict(lambda: [0, tree()])

    def printtree(node, indent=0):
        padding = indent * ' '
        for word, (count, child) in node.iteritems():
            print "%s%s %d" % (padding, word, count)
            printtree(child, indent + 2)

    wordtree = tree()
    for line in sys.stdin:
        node = wordtree
        for word in line.split():
            node[word][0] += 1
            node = node[word][1]
    printtree(wordtree)

robertduncan2• 14 years ago

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

zheng• 14 years ago

Unless of course you only need to write one line. Not every use of git requires complex formatting in commit messages. Almost all of my git repos are used by me alone, and one line is enough. Obviously this isn't the main purpose of git, but I'm guessing I'm not the only developer using it this way.

socmoth3• 14 years ago

I agree with you. It isn't obviously better to write long verbose messages. I commit dozens of times an hour and try and keep each change as small as possible. Ideally, so small a single sentence is a perfect description.

I'm fond of speaking tersely.

ismarc2• 14 years ago

Additionally, there's significant benefit to lots of tiny commits with a 1 sentence what changed and the squash the commits and write the larger, better formatted one based on your list of one-liners.

parfe• 14 years ago

  $ git commit -m "It is possible
  to write a multiline
  commit message
  using the -m flag."

Just hit RET or C-j while you have an open quote and you can send newlines to your heart's content.

gee_totes• 14 years ago

Why?

robertduncan2• 14 years ago

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... gives a good description.

decklin• 14 years ago

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.

[1] rudimentary script: https://github.com/decklin/bin/blob/master/hprune (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)

B-Con• 14 years ago

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.

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.

wccrawford• 14 years ago

I agree. You need to look at that net time saved, not the gross.

In addition, if you're at a terminal on a new server, or someone else's station, all those aliases will be gone.

For me, that means any special aliases or scripts had better be awesome enough to convince someone else to use them... Or infrequent enough that I can't be bothered to remember the whole command. Or just so useful that it's worth overriding the above.

Shortening a 3-letter command into a 1-letter command is not going to fit into the above. Especially when I will have typed 'git' before I remember that I can just type 'g' instead, since I touch-type without looking. It just flows out.

jerf• 14 years ago

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.

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 a 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.

socmoth3• 14 years ago

I completely agree. I would love to see something that beeped at me when I didn't use an aliases which is already in my system.

FuzzyDunlop• 14 years ago

Maybe something like what emacs does when using a full command? It helpfully informs you of the shortcut for it, if one is available.

tikhonj2• 14 years ago

I've certainly found this the case when creating new key bindings for Emacs. Of course, this now means that other people have a little bit of trouble using my Emacs because some of the basic key bindings don't work any more and some of them do something new :).

I'm now using this strategy whenever I want to change something like a common command or key binding--essentially anything that is a habit I don't have to think about.

Another thing to note is that it really helps if you come up with the alias or new key combination yourself. I find it takes almost no effort to memorize a key binding I choose myself as opposed to remembering a new one that comes with the tool itself.

sciurus• 14 years ago

For vim I benefitted greatly from

  " disable arrow keys
  nnoremap <Up> <nop>
  nnoremap <Down> <nop>
  nnoremap <Left> <nop>
 nnoremap <Right> <nop>

rm999• 14 years ago

I may misunderstand what you mean, but isn't unmapping standard commands bad for portable scripting? Not everyone will have the same aliases as you; for something like git commit this may not matter, but it seems like a bad habit to me. And again, I may misunderstand what you mean, I don't even know how to make it impossible to type a command.

ori_b• 14 years ago

Aliases typically only apply to interactive usage. From 'man bash':

    Aliases are not expanded when the shell is not interactive,
    unless the expand_aliases shell option is set using shopt (see
    the description of  shopt  under  SHELL  BUILTIN COMMANDS below).

pkrumins• 14 years ago

Also see an old article of mine titled "Working with git? These aliases will save you hours!":

http://www.catonmat.net/blog/git-aliases/

com2kid• 14 years ago

If you have to do it once, fine. Some work needs to be done.

If you have to do it twice, think it over a bit.

If you have to do it a third time, automate it.

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.

I even know a few people who have used most of the alphabet to create single letter scripts. That is efficient!

DeepDuh2• 14 years ago

That's exactly how a shell should be used IMO.

secoif• 14 years ago

Aliases to cd into directories? You need to check out autojump style tools! Will change your life.

e.g. https://github.com/rupa/z

I very, very rarely type cd by hand anymore, mostly just use z and popd

dredmorbius4• 14 years ago

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.

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.

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.

dllthomas2• 14 years ago

>But it bears pointing out that this is much like comparing a pogo stick to an F-22 / Boeing 777 / Mercedes E-class.

Well, more like comparing an early horse drawn carriage to the latter three. A pogo stick has always been a toy - never designed to get work done, however inefficiently. Primitive command lines were still attempts at letting you get work done, they just weren't as good as what we have now (or, in some cases and for some purposes, contemporary graphical alternatives).

dredmorbius4• 14 years ago

It's also worth pointing out that many current CLIs are still grossly crippled. The DOS / CMD.exe environment in Windows. Oracle's sql client. Sun/Oracle's default tcsh. Cisco's IOS. All of which lack one or more of readline, tab completion, command history, pipelines, and other, really basic, modern shell features.

One of the first selling points for Linux when I first started exploring it a decade and a half ago was that while some of the internals were a tad crufty, the userland (much of it, admittedly, GNU) didn't suck, and didn't suck in a much bigger way than stock commercial proprietary unices did suck.

Pogo stick or oxcart, the point is that many such tools were, or are now, pretty much intentionally crippled.

halostatue• 14 years ago

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.)

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.

dllthomas2• 14 years ago

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.

riffraff• 14 years ago

came here to write this. For example, if I look at my history, I have a bunch of `git diff` and `bundle exec rake test`, which actually correspond to `<C-r>-d-i` and `<C-r>b`, and a few `heroku ...`which amount to `he<Up>`.

The single command to actually count this occurrences required way more typing.

rocky1138• 14 years ago

Does this include the times where the user presses the 'Up' arrow key to retype a previous command?

I think that would skew the results a bit if so.

carb• 14 years ago

If you want to keep your fingers on the home row, I find `ctrl p` to be more comfortable and faster.

elarkin• 14 years ago

Likely yes. He mentions that he turns off deduplication for the experiment.

You're right that it does not accurately describe his typing, but it does describe which commands he uses most... which is about half as good.

beambot• 14 years ago

Better yet, just set your history to 10k-20k+ items and use reverse-search (ie. Ctrl+r in bash) to recall your old commands. Navigation aside, about 80-90% of commands I use regularly are already in the shell history.

natep• 14 years ago

I'll often use Up/^p/^r(i-reverse-search) to find a previous command and edit it's argument, which is where the tree nature of this tool would come in handy. If I 'type' the first n terms of a command enough times, it might be better to alias that part of the command rather than navigate my history and then edit the rest of the command repeatedly.

TazeTSchnitzel• 14 years ago

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

techpeace• 14 years ago

For improving your git-command-related efficiency, you could always use the excellent git-sh by Ryan Tomayko (CTO of GitHub): https://github.com/rtomayko/git-sh

stretchwithme• 14 years ago

Tower is pretty awesome too if you aren't wedded to the command line. I can do things in seconds that would take me awhile to figure out how to do on the command line.

samspot• 14 years ago

I was inspired by this to share the rebuild alias I've finally come up with:

  sf = tcstop && mvp stretch-base,stretch-app && tcs
    tcstop = ~/tomcat6/bin/catalina.sh stop
    mvp = mvn package -projects
    tcs = cl && tcstart && 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

X-Istence• 14 years ago

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.

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).

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.

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.

notatoad• 14 years ago

Is typing git commit over and over again really so terrible? It's pretty much muscle memory anyways.

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.

DeepDuh2• 14 years ago

Whenever there is an argument of a CLI being suboptimal you can be sure that the counter is going to be "but it's all in my muscle memory!". CLI itself isn't efficient, it just FEELS efficient. Its real strength is the scriptability, such that repeating tasks can be substituted. If you deny yourself that power, you'd probably be better off with a GUI and good use of hotkeys.

Now, I'm aware that there are different usage scenarios. A typical developer only ever works on a handful of systems at the same time period - which makes handling your personal set of scripts a viable option. Administrators are an entirely different beast.

mhd• 14 years ago

I'd say that administrators who can't set up a system that allows them to have individual setups maybe should pick another job. Even if you're sharing a root account, you could still source your unique shortcuts and aliases. The only thing prevent you from doing that is privileges, of course (although even then there are partial workarounds).

But there is a point about optimizing typing. If you're just going to replace "git" with "g", you'll save two characters. You're probably not quite down to a third of the time, but there will be a measurable difference. But given that there's some overlap with other actions (e.g. you might already be pondering your commit message), the measured productivity increase will probably be pretty small.

In cases like that, it's probably better to look at the whole workflow, so you're not just saving time at the micro level. Save/unify several steps of the whole procedure (e.g. combine save-commit in your text editor).

And then consider that by reading this thread, you've spent x minutes that you'd have to work very hard to get back by saving keystrokes ;)

smoyer• 14 years ago

CLI is itself efficient in the sense that you're not lifting your hands from the keyboard to manipulate the mouse. Beyond that - scripting makes it more efficient.

Huffshell: You probably type too much.

Related Stories