We just moved to a new suite @ work today, and the “trauma” of the change has made me a little more braindead than usual, so I’ve focused myself on dissecting a few commands (one necessitated by my work to-do list, one not). Starting with the latter here.
Two points that I definitely will expand on later:
- I have a great interest in being a unix / command line power user, but at the same time I’m not going to replace my recreational reading with my copy of Unix Power Tools (O’Reilly). So I try to pick up the little bits that emerge from the noise (I probably over-filter) that are appropriate to my skill level and what I’m working on at the time, and try to commit them to memory by way of understanding them completely (or as best as you can understand “this symbol means [insert meaning here]“).
- My text editor of choice is vim. Why? Because when I had to choose a text editor, my (now ex) boyfriend was using it, and I didn’t want to learn them both (vim / emacs). Yeah, so much for puffing out my chest and defending vim’s superiority – the so-called holy war (and as emerges in other technologies) is kind of silly.
- Going off of (2), I’ve come to believe that allegiance to any one utility / tool / language / etc as programmers and technophiles are wont to do is misleading. My experience is not that “x rules for this list of reasons and is better than y and z for these reasons”, which you get in pretty much any introduction to a technology or language, but rather “Everything sucks for its own reasons.” And you choose what sucks in the least annoying ways. I think this probably speaks to my personality more than anything.
Anyhow, one of my recent discoveries on Twitter is commandlinefu, which aggregates command line tricks from its varied followers. You can also find the commands at their website, which is a bit easier to deal with than the twitter format if you aren’t in the mood for streaming command line goodness. I honestly filter a lot of it as noise, but occasionally something jumps out that doesn’t look like it will totally derail me (as too much of a lesson in itself instead of an enhancement), and today it was this: “open the last file you edited in vim”. I tend to re-open files a lot, either because I’ve forgotten to use :sh or simply because I forgot an extra detail, so it seemed worth digging into.
My interest in using this as a (baby) step towards power userness was making sure I also understood every component of it, which is the slightly trickier part. A little digging around, though, and I’ve learned some things about vim that I didn’t know before while picking up a handy shortcut.
Here’s the command as presented on commandlinefu:
alias lvim="vim -c \"normal '0\""
I was specifically interested in the command itself and not the alias:
vim -c \"normal '0\"
The backquotes are because this alias would go in a .bashrc or .aliases type file, so if you were running this sans an alias on the command line, you wouldn’t need to escape the quotes and it would be:
vim -c "normal '0"
Breaking this down. The -c option in vim tells the program to execute a command after the first file is read. In this case, the command is “normal ’0″. The quotes are required because this command contains a space.
“normal” was harder to grab. Try searching “vim normal command” and you’ll have to sift through a lot of results about vim’s “Normal Mode”, which is related but not quite what I was looking for (I wanted confirmation of what the command was doing, not an assumption). I finally found a description of this command here: various commands reference (search the page for “normal”). The command means “execute normal mode commands”; i.e. the myriad commands you can run from the default normal mode in vim.
The normal mode command we’re running is ’0. This refers to a register that’s stored in .viminfo, a file that typically lives in your home dir with your .vimrc and the ’0 value is written to it every time you exit vim or run the :wviminfo command. ’0 corresponds to the file you have opened and the character you’re at when .viminfo is written. In other words, the exact place you were located when you last exited vim. If you look at the starting vim documentation, this is documented really nicely, right down to its usage in the command / alias that made its way to commandlinefu.
Too detailed for you? Pleasantly detailed? I’m curious – I feel like I rarely see stuff broken down like this, and for me it’s really satisfying to be able to understand what’s going on from beginning to end, even if I end up using an alias from here on out. I even pried open my .viminfo file and had a look at the registers. Extremely satisfying.
Next, a slightly hairier beast – patching a particular file in git (as someone who is a novice in git, and has never used the patch application.