Let’s say you set up a brand spanking new Unix/Linux box somewhere, or gain access to a bran new shell account on which you expect to be doing some work. What are the top three things you install first?
I’m not talking about standard shell tools that are part of the coreutils pacage on most systems – we all love things like ls, grep or wget but these things are usually always there. I want to know what are your top three indispensable things that may or may not always be there on a stripped down fresh install.
Here are mine:
You would be hard pressed to find a Unix or unix-derivative system that does not ship out of the box with a copy of vi. Most linux distros actually ship vim and simply alias it to vi in compatible mode. But, Vim 7.3 is still pretty hard to come by. Unless you are rolling out brand spanking new fresh release, chances are you will have version 7.2 on your system.
Why do I prefer 7.3? Well, it has a handful of features that I grown to like and rely on:
- Persistent Undo is huge help. Unlike most editors, Vim 7.3 will preserve your undo history even after you save and close the file. This is like having a poor-man’s version control for your files, without actually using version control.
Unlike most text editors who track edits in a linear way, Vim keeps the undo history as a tree data structure which you can traverse back and forward without actually losing any work. There exist plug-ins such as Gundo which help you visualize and browse your past edit branches with ease.
As you can imagine, once you get used to undo history persisting after file is saved and closed, it is hard to wean yourself off of it. It is just too useful and convenient of a feature not to take advantage off of it.
- Relative Line Numbers – 7.3 has this nifty feature which numbers the lines relative to the cursor position. So the current line you are editing is always line 0, and the numbers grow up and down away from it. Why on earth would you want that? Well, it’s a Vim thing really. Vim commands don’t take absolute line numbers or ranges as arguments – they take offsets. So instead of saying something like “do this on lines 5 through 7″ you instead say “apply this to the next three lines”. Which means that seeing at a glance that the end of the code block you want to manipulate is N lines away from your cursor without having to count is extremely beneficial. It makes you more productive.
Could I survive working in 7.2? Yeah, probably – but if I can help it, I install 7.3 just to have an uniform work environment across all the machines I work on.
As to why did I include Vim itself on this list? I believe I already answered this question quite throughly.
I found out about tmux only few months ago, but I’m already addicted to it. It is a tool so indispensable to me that I will go to great lengths to compile it from source if it happens to be unavailable on a machine I need to be using. Especially if it is a remote machine.
Tmux is a terminal multiplexer – a drop-in replacement for the venerable screen. If you have never used screen, I am about to rock your world my friend. This is the tool that will revolutionize how you work on the command line.
Here is how I explain this tool to complete n00bs: you know how vim and emacs have buffers that you can toggle between or even put side by side in split-screen mode? Terminal multiplexers give you exactly that – but for your shell.
Let me give you a hypothetical example: let’s say you ssh to a server and you are editing some config file. You need to change some value, but you don’t remember what are the allowed values and ranges for that setting. What do you do? Well, you could Ctrl+Z out of your editor, check the man page, and fg back… Or you could grab the mouse, and look the value up online, or locally.
Or you could split the screen, and open the man page side by side with the text editor like this:
Here you see me editing .tmux.conf viewing the man page, and keeping my eye on how hard PogoPlug is working by running top. All on one screen via single PuTTY SSH session from windows. And if I accidentally close my PuTTY window, all I need to do is to ssh back into the box, and issue a single command:
tmux attach -t session_name
All the stuff that I had open doesn’t close when my connection is lost, but keeps on chugging. This is great for big compile jobs – you just type in make, log off and go eat your dinner while the code compiles in the background.
Why Tmux and not Screen? Because it is easier to use. The key bindings are easier to configure, the screen splits look aesthetically nicer. And of course it is just much more friendly to use. For example, in Tmux opening a new shell instance in a vertical split screen buffer is a single action, whereas with screen it is usually two (first you split the screen, then you create a shell session in the new buffer).
Without git I can’t get anything done. For one, I keep a lot of my config files under source control. When I set up a new machine, I usually immediately instal git, so that I can clone my .bashrc, .tmux.conf and .vim/ files and get my working environment in order. Only after I do all that I can start doing actual work.
Git is useful for more than that though. My personal philosophy is that anything I have spent more than 10-15 minutes creating ought to be under version control of some sort. This is sort of a rule to live by, and every time I bent or violated it I got burned pretty harshly. But do not rely just use it locally – a local git repository can be easily blown away along with your work by an accidental deletion, hard drive failure or a myriad of other accidents. If it’s worth sharing, put it on Github. If it is private, show it away on BitBucket. If you do not ever want it to leave the confines of your LAN, set up bare repository on another machine you own, and push your work there regularly so it is in at least two places (well, four – because you are backing both machines up, right?).
Granted, git is not the only source control system out there but it is one I have become fond of. It runs on just about every platform, and once you grok the basics it is actually fairly straightforward to use – especially for small, single person projects. It has great remote services, and pretty good assortment of client side tools (I hear good things about the Github clients for Mac/Windows and stuff like TortoiseGit).
What are your top 3 tools that you couldn’t live without? Let me know in the comments.