I sort of did the opposite. I took all my aliases that were created because I couldn't remember something (commandline switches, non-trivial tool invocations, non-trivial regexes, etc.) and just set the alias to echo the command. Whenever I'd attempt to use the alias, it would just print and I'd have to retype it by hand. Eventually I learned everything I used to have trouble remembering and have became much more fluent with command line utilities and bash.
I still leave convenience aliases intact. Nobody needs to be typing --color=auto every time they ls.
If you want to make it so that any changes stick, you have to make it so the old way doesn't work anymore. I remapped my Caps Lock to several things over the years, but it isn't until I learned to unmap the original key that any of them stuck.
If you turn out not to like it, switch back.
It's a bit of a challenge to wrap something like 'git' with a shell script that spanks you for doing the wrong thing, but that's a good shell learning exercise.
A point scheme is still too diffuse and the feedback still too slow vs. It Didn't Work occurring instantly. You'd be amazed at how quickly you learn new keystrokes this way.
(The interesting logic happens elsewhere, but the above template demonstrates that one can wrap git without too much trouble and without reducing functionality.)
For aliases, convenience functions, and fancy widgets, my philosophy is one word: wait. I make myself go through the trouble of doing it the usual way for a little while. This way, I usually end up with much more domain knowledge and a much more elegant solution than if I'd rushed in to make things easier right of the bat.
For example, I don't have `alias gs='git status'`. Just `alias g=git` works great, and git has its own awesome alias system with tab completion that gets me the rest of it. So instead of `gs` I type `g s`, and I get tab completion on all the flags.
Neat! I'll try that using the g() function. I would replace your $* with "$@" (in double quotes), though, so it doesn't try to re-split your arguments by the IFS. (Yes, $@ is a gigantic hack, but a necessary one.) See http://stackoverflow.com/questions/3008695/what-the-differen...
I don't know. I thought it was because if you pipe into "less," it will wait for you to hit 'q' until letting you carry on entering commands. But "more" does not have this behavior.
This is cool. I am thinking of gamifying my alarm clock in the morning, so that I earn more XP by not snoozing, and just waking up.
Primarily it is a way to help give my mate some experience programming, but I also hope that it will help kick my morning alarm snoozing habit.
In the future, I thought it would be cool if you could just pass it new config files to allow gamifying everything. For example, if you want to kick your fast-food-for-lunch-habit, then allow the gamify-everything app to award XP and trophies for things such as "Making your own lunch for X straight days"
[bashmarks](https://github.com/huyng/bashmarks) does something similar: it provides a command to set a named bookmark on the current directory, one to jump to a bookmark, and one to list bookmarks.
(It lacks all of the magic of z -- it doesn't try to learn how you work. It's entirely explicit.)
Instead of creating aliases, I'm using z (https://github.com/rupa/z) for that. You use it instead of cd to navigate to the most frequently used directories anywhere.
However, I am wary of "smart" things that change with usage. I like my tools to be consistent and predicable. For example, I am constantly getting burned by alt-tab
That said, I imagine the "frecency" component of z makes it more reliable.
I still leave convenience aliases intact. Nobody needs to be typing --color=auto every time they ls.