Unix editors and pagers

There have traditionally been several areas in Unix where the program to invoke has been a matter of user, or system administrator, taste. These include the preferred shell, the current printer, the C compiler, and (discussed here) the preferred editor and pager utilities.

Long-standing traditions

Traditionally, three environment variables have been used to encode these preferences. Instead of hardwiring a program name, applications are expected to query the values of these environment variables, subject them to a PATH search (as if by the execvpe() library function) and execute the resulting program image file in order to invoke an editor.

EDITOR

This names the line-mode editor program to invoke. It is what the mailx command invokes in response to ~e. A reasonable default when the variable is unset is the standard ex utility.

VISUAL

This names the full-screen editor program to invoke. It is what the mailx command invokes in response to ~v. A reasonable default when the variable is unset is the standard vi utility.

PAGER

This names the pager program to invoke. A reasonable default when the variable is unset is the standard more utility, although (as the standard notes) in the System 5 side of the universe the de facto standard was the pg utility.

Environment variables are, of course, per-process. These are more fine grained than even a per-user setting, as they permit users to temporarily override them for specific processes.

Sometimes shell scripts do not quote the uses of these variables, as they properly should, so values that contain whitespace have uncertain behaviour. In some shells, in the default mode unquoted variable expansion does not cause further field splitting. In other shells, it does.

These variables have a few other effects that are not directly related to invoking programs. For example: Both the Z shell and the Korn shell scan then for various patterns, and decide based upon the patterns found what keyboard binding (e.g. emacs, vi) to employ.

More recent additions

Some Linux operating systems have muddied the water somewhat.

Debian's "alternatives" mechanism

The "alternatives" system originated in Debian, and by 2002 had been included in RedHat. It is also to be found in OpenSUSE.

Two commands that are re-mappable by this system are editor and pager, and the alternatives system re-maps their user manuals as well so that man editor and man pager open the appropriate user manuals. These will map to one from a selection of currently installed editor and pager programs. For example:

jdebp % update-alternatives --list pager
/bin/less
/bin/more
/usr/bin/pg
/usr/bin/w3m
jdebp %

This is a system-wide mapping, controllable by the system administrator using the update-alternatives utility. It does not replace the environment variables, because it does not permit a fine-grained level of control that allows users to have individual preferences, or to temporarily override those preferences (within, say, a particular interactive shell session).

Thus on Debian and RedHat it can be argued that the reasonable default in the absence of the VISUAL environment variable is editor rather than vi, and the reasonable default in the absence of the PAGER environment variable is pager rather than more. And indeed one finds that some softwares, such as the man-db package, compile their hardwired fallbacks as editor and pager on "alternatives" systems and as other programs on non-"alternatives" systems.

Debian's "sensible" utilities

The good sense of the Debian "sensible-utils" package is debatable, but what its sensible-editor and sensible-pager tools do, among other things, is split out the code for consulting the traditional environment variables into a pair of common programs. Instead of looking at the environment variables and providing fallbacks themselves, applications can just hardwire the names sensible-editor and sensible-pager into (say) a call to execvpe(), and rely upon those tools to implement the traditional mechanisms.

They also do a selection system of their own. A user's selected editor is recorded in a .selected-editor (POSIX sh) shell script in xyr home directory. But since not every application uses this system, this file is not a general-use configuration mechanism that replaces the traditional environment variables. Indeed, the .selected-editor mechanism is a fallback when the environment variables are not set, a kind of per-user equivalent to Debian's "alternatives" system. (There is no .selected-pager mechanism.)

The fallback order for sensible-editor is thus:

  1. the per-process environment variables

  2. the per-user selected editor in .selected-editor

  3. the system-wide editor as set by Debian "alternatives"

  4. a few hardwired names

The fallback order for sensible-pager is thus:

  1. the per-process environment variable

  2. the system-wide pager as set by Debian "alternatives"

  3. a few hardwired names

The wrong thing to do is employ sensible-editor and sensible-pager as fallbacks for missing environment variables. For starters, it duplicates mechanism. These programs should replace such a mechanism. Unfortunately, several programs, most notably the Debian version of Vixie crontab, do exactly this wrong thing.

The downside to this is that it introduces another package dependency into any application that uses these utilities. It also can result in some surprises to those expecting the traditional mechanisms, as the fallbacks when the traditional environment variables are unset (and the .selected-editor mechanism is not set) are to the pager and editor set by Debian's "alternatives" system. And, sad to say, the .selected-editor file does not respect the XDG_CONFIG_DIR mechanism for locating configuration files.


© Copyright 2020 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.