Over a million developers have joined DZone.

Let's Put an End to Unix Editor Snobbery

DZone's Guide to

Let's Put an End to Unix Editor Snobbery

· DevOps Zone ·
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

I recently had a converation with a friend that could be paraphrased as follows:

Friend: Whoever defined nano as the default crontab editor for Ubuntu deserves a whipping with a rusty chain.

Me: What should the default be then? nano seems like a sane default. Anyone who would pick vim or emacs presumably knows how to change $EDITOR anyway.

Friend : Anybody editing crontab as root has no business using something other than vim or emacs. If a person needs to use nano, they have no business managing systems.

This is unhelpful.

I am going to rewind to 2005 or so. I was capable of building my own computers and throwing Windows on them. I had barely touched unix like systems before - although I managed to bumble my way through doing what little I needed to do on the two Solaris machines at work at the time.

I then got a wild hair one weekend and setup my machine to dual-boot between Gentoo and Windows (I really couldn’t give up gaming). I forced myself to go through installing and using Gentoo, which is what I perceived to be the one of the most expert Linux distributions at the time. I wanted the most minimal of handholding. Guess what editor the Gentoo documention recommended the new person to use? Yes, that’s right… nano. I shortly learned to use cron roughtly 2-3 days after I finished the gentoo install. Cron is hardly a sophisticated piece of software to use and configure. While having a really nice text editor for it could be recommended, as the aforementioned vim/emacs have really nice syntax hilighting for it, editing crontab is very much unlike programming in that you would be insane to use a barebones editor to manipulate it.

Of course, if I were actually friends with the quoted individual above at this point in my life, I would have convinced myself to slog through learning vim or emacs over the course of the next week or three, all to do this:

0 * * * * /home/whaley/bin/doSomething.sh

Does that really require mastering a modal editor or playing escape-meta-alt-control-shift keyboard jockey? Of course it does not. But, who knows if I would have kept at it if learning to use a linux system meant proficiency in such editors.

What really is required for this scenario above is the user to understand what they are doing with cron and to understand the editor they know the best well enough to accomplish that job. Right now lots of new users of linux go to Ubuntu and selecting Ubuntu is the logical choice for the potential future guru who wants training wheels to start off with. Expecting someone who purposefully chose that particular distribution to learn one of those editors is, at best, snobbish.

While there may be a (strong) correlation between the proficiency of using these editors to having a strong linux adminstration skillset, it is always useful to remember that correlation does not mean causation. Editors are just a tool. They are not a right of passage or a shibboleth in to some some advanced society. Treating them as such will do nothing more than serve as a rejection notice to anyone who might know them yet or is not fully comfortable in using them.

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}