Today I want to discuss options for a key critical tool: the editor. The editor can be one of the most important tools, if not the most important tool, for systems administrators. It's also the tool that will generate a tremendous amount of – shall we say – discussion , possibly resulting in the exchange of insults and general loathing of our fellow human beings. Despite the risks, discussing editors is a useful, interesting, and worthwhile exercise. I argue that systems administration needs a command-line editor, because it can be used even if X windows isn't working or isn't installed on the servers. Knowing how to use SSH and a command-line editor has saved my admin bacon on several occasions. You don't have to be an expert, but you do need to know enough commands to edit files and be comfortable with the editor.

After knowing and being comfortable with a command-line editor – enough that you can SSH to a server and edit a configuration file – you can either choose to learn a second graphical user interface (GUI) editor or not. A GUI editor can be advantageous if you are a visual person (like me), but it's not a requirement. Personally, I use a GUI editor or two when writing code and writing documents.

Assumptions and Ground Rules

Before jumping into editor options, I want to put down the assumptions I'm using in my selection of what editors to write about. The starting assumptions are:

• The focus is on open source editors.
• The desire is for multiplatform editors, although this isn't a hard and fast rule, but at a minimum it has to run on Linux.
• The focus is on text editors and not Integrated Development Environments (IDEs). IDEs are a different beast with different feature sets; however, a few editors I will mention can function as a very basic IDE.
• My goal is to present editor options and list some of their more significant features. I will not be rating or judging the editors. I might also miss some features of the editors – please don't rely on this article for information to make a decision – try out the editors that interest you.
• I will likely not include editors that other people use and recommend. I'd love to hear more about them, so please contact me.

I've divided the editors into two sections: command-line (CLI) editors and graphical user interface (GUI) editors. Let the mayhem begin!

Command-Line Editor Options

Eons ago, when I started with *nix, CLI editors were all we had, so you learned them very quickly. Now that X is so popular, many people don't bother with CLI tools. Therefore, not many open source CLI editors are available today. However, I promise you that learning a CLI editor for systems administration, particularly in HPC, will help you at some point in your career (and they will carry you around the data center on their shoulders afterward).

CLI editors can work in basic terminals and don't require X Windows or any type of window manager or similar tool. CLI editors allow you to edit files on a server that doesn't have X running or installed. This can include SSH-ing into a remote server, using a parallel shell tool to run commands on multiple nodes, or both scenarios. Considering that, many times, compute nodes don't have X installed, being able to triage, debug, and fix a compute node with a simple CLI editor is very valuable.

Below are four CLI editors that are commonly available with most Linux distributions. There are a couple of others, but they aren't very common and don't seem to have as many users. Therefore, it is unlikely that they will be installed on servers. I'm going to start with probably the oldest CLI editor, but one that serves as the foundation for another editor.

ex

Ex [1] was written by Bill Joy [2] in 1976 as something of a replacement for the original *nix editor named ed [3] (ed was developed in 1969). Bill Joy modified a development of ed, named em, to create ex.

Ex is a CLI editor, in that it operates on individual lines or groups of lines that you have to specify at the command line. In today's *nix world, it is a "personality" of Vi and provides some functionality that Vi cannot, so if you have learned Vi, you already know some ex commands.

You can start ex on the command line in most Linux distributions by simply typing ex. This is typically the CLI personality of Vi. One feature that ex originated is the substitution command, which is what you use in Vi to make a substitution on a specific line, set of lines, or the entire file. For example, you can run the command:

: s/XXX/YYY/g

This commands substitutes the string XXX for the string YYY, normally for the current line. However, in this case, it does it for the entire file because of the g option at the end of the command.

The slash (/) is just a delimiter to separate the string you are replacing and the new string, but you can use other delimiters if you like – you just have to use them consistently (i.e., they have to match). This is especially useful if you want to substitute a string that includes the slash. I tend to use + as my delimiter when a slash is involved.

I wouldn't say that ex is the ideal CLI editor, but knowing a bit of ex in conjunction with Vi can be very useful.