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.)
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.
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.
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...
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"
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.
[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.)
32 comments
[ 9.9 ms ] story [ 281 ms ] threadIf 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.)
I still leave convenience aliases intact. Nobody needs to be typing --color=auto every time they ls.
Hm. All of my aliases are convenience aliases:
cls=clear # Yes, I started out in DOS
ls=ls --color=auto
ll=ls -l
ll.=ls -al
And that's it. It's amazing how different peoples' workflows become once a tool allows a certain level of customizability.
ctlr + l is your new best friend.
My remaining minor complaint: alt-k loses the prompt.
I use xterm (goes to check before I make an ass out of myself) and I'm utterly shocked this works. Amazing. Ctrl-l does indeed work.
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.
I've never messed with bash completion before, but it was as simple as adding this to my bash_aliases:
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"
alias ch="ch ~/Repositories/my_project/foo"
alias cn="cd ~/Repositories/my_other_project"
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.
(It lacks all of the magic of z -- it doesn't try to learn how you work. It's entirely explicit.)