Let the Editor Wars Begin!

Today I thought I would steer away from hard-core high-performance computing (HPC) topics – but not too far – because I want to discuss options for a key critical HPC tool: the editor.

The editor can be one of the most important tools, if not the most important tool, for administrators of HPC systems. 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 in general, and HPC in particular, 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 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).

Command-line editors can work in basic terminals and don't require X Windows or any type of window manager or similar tool. Command-line 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 was written by Bill Joy in 1976 as something of a replacement for the original *nix editor named ed (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 tile. 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 XXX and YYY (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 be the same). 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.

vi

Bill Joy designed vi to be the "visual mode" for the ex editor. It was part of the original ex via the visual command but wasn't its own binary until about 1979. Vi is a screen-oriented editor, in contrast to the line orientation of ex.

In general, vi is a modal editor. It operates in a particular "mode" such as Insert mode or Normal mode. When in Insert mode, for the most part, the keystrokes are interpreted to be text that is inserted into the file. In Normal mode, the keystrokes are taken to be commands. Knowing which mode you are in is one of the earliest aspects of vi that need to be mastered.

Figure 1 shows vi running running in Normal mode on my Linux CentOS 6.8 desktop. At the bottom of the screen is the colon (:) prompt for the vi commands.

Figure 1: Vi 7.4.629 on CentOS 6.8.

The rivalry between vi and the next CLI editor, Emacs, is HUGE.

Emacs

Emacs is arguably the “Swiss army knife” of editors. It is extremely extensible and customizable, including the extensive use of macros. It has more than 2,000 commands built-in to the tool and includes a dialect of Lisp named Emacs Lisp that allows users to write new commands. Development started in the 1970s at the MIT Computer Science and Artificial Intelligence Laboratory and continues to this day. Richard Stallman started work on GNU Emacs in 1984. Emacs has had a number of versions over the years and has been forked several times.

One of the features that attracts people to Emacs is its ability to work with other applications (i.e., very *nix-like). For example, from within Emacs, users can read their email, compile code (i.e., similar to an IDE), use a calculator, interact with a spreadsheet, check newsfeeds (RSS), or browse the web. Essentially, Emacs becomes the center of one's working environment. In fact, some users only use Emacs because it can reach so many other tools. What you use Emacs for is up to you, and you are not forced to use it for everything.

Emacs can split the main editing window into separate "panes" (Figure 2). It has had this ability before GUIs were available. Each pane has a status bar at the bottom. The classic example of splitting the main window into panes is to have one pane on top for editing code and one pane at the bottom for compiling and testing the code. This allows Emacs to be used as an IDE. In CentOS 6.8, the command emacs starts the GUI version.

Figure 2: Emacs 23.1 on CentOS 6.8.

Nano

Nano is designed to be a simple editor that can be used in a console. It is based on Pico, which is part of the Pine email client, but it has had some functionality and new features added, such as regular expressions.

In the past couple of years I have seen much more interest in Nano (Figure 3), partly, I believe, because Nano has the command help at the bottom of the screen at all times, which, if you don't use Nano very often, can be very, well, helpful. Another reason it might be so popular is because a new influx of users who have no preconceived notions of a *nix editor such as vi or Emacs have adopted the easiest CLI editor they could find.

Nano was released in 1999 as free software. It joined the GNU Project in 2001. Development under this umbrella proceeded for several years until June 2016 when the current principal developer and the other active members of the nano project decided to leave the GNU project, leaving GNU nano intact but taking active development outside of GNU (a fork). This move was taken because of their objections over the Free Software Foundation's copyright assignment policy.

Figure 3: Nano 2.0.9 on CentOS 6.8.

JOE

The last CLI editor I want to present is JOE, which stands for “Joe’s Own Editor,” available under the GPL license. JOE was started in 1991 when applications such as WordStar and Turbo C were very popular. JOE’s keystrokes are similar to those in these two programs. JOE can emulate Emacs and has a link to a binary named jmacs. It has similar emulations for Pico (jpico) and WordStar (jstar).

According to the Wikipedia article for JOE (Figure 4), it was included in many early Linux distributions, so it has a pretty reasonable user base. Its development has bumped along, with the latest stable release in September 2015. One nice feature in JOE is that the shortcut key for help is always shown on the screen.

Figure 4: JOE 3.7-4 on CentOS 6.8.