Your Top Three Unix Tools

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:

Vim 7.3

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.

Tmux

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:

Using Tmux on a remote server

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

Git

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.

6 Responses to Your Top Three Unix Tools

So I’ll add three more:Ranger file manager is a huge timesaver when browsing a directory tree looking for something. I keep an instance open all the time (in tmux of course!) next to a regular terminal window. It’s got a great set of default file-opener rules as well.

Rsync — for obvious reasons! It for some reason isn’t installed by default on Arch.

As a Debian user, I automatically get everything marked essential, and only those since I always do a netinst. That includes wget, GPG, and all the basic shell tools you said don’t count anyway.

The first two are obvious and come right out of your book. Like you, Luke, I need my text editor, so I install Emacs 24 — 24 because my Emacs configuration currently requires it. However, first I install Git so that I can pull down all my configuration files.

The third one is a little trickier. Since you mentioned it, screen and tmux are nice but I can get by without them. I’d probably pick a development tool like a compiler, etc. Emacs can fill this role pretty well on its own, being a personal Lisp machine, but it’s inadequete for many kinds of things (slow, limited to 29-bit integers). While OpenJDK or GCC sounds useful, they’re really hard to use without a build system (Ant, Maven, make, etc), which would require at least one additional package.

So, right now I’d pick SBCL to get myself a Common Lisp environment, which I can trivially integrate with Emacs. It comes with a sort-of build system, ASDF, so that’s covered.

Scott’s mention of Keychain was right in line with my thoughts. I initially considered that as my third package, but I can live without it if I had to. A dev tool is more important for me.

Anyone reading this know what Emacs is. Rlwrap is a program that adds instant readline support to any program. Just type “rlwrap ” and there you go. I do a lot of lisp programming so typing this really nice when starting a REPL.

Also, sshfs is the easiest way to securely mount a remote filesystem. You can use without root permissions and you can mount any directory you can reach through a regular ssh session.

If you open a tmux window and then split it into two panes you can do the following:
Open Vim in one pane and a language interpreter (irb, python, lua, clj, …) in the other.
Write some code fragment in Vim and press ctrl+c ctrl+c while the cursor is still in the block of code you have just written. This block of code is then inserted to the other pane and immediately executed by the language interpreter (in the case of python you usually need to add another newline).

The first time you press ctrl+c ctrl+c tslime asks you where it should paste the stuff. You then have to select the session, the window and finally the pane.

This plugin is great for writing and directly testing code fragments. And if you made a typo it’s much easier to quickly fix it and send the code back to the interpreter.

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page.Click here for instructions on how to enable JavaScript in your browser.