Configuring the Bash Shell (and Korn Shell) to Permanently Use vi-mode Editing

The GNU bash shell, as one might expect, uses Emacs key bindings to perform history and editing in the shell. Vi key bindings are available, and can be set with this standard command (just like in ksh):

set -o vi

My fingers have gotten this sequence of letters ingrained in them so I don’t even have to think about it – and I type it almost automatically after login.

However, there is a way to set up ksh to automatically set editing to vi mode. If the VISUAL variable is set to a value like vi, then the editing mode will be set to vi mode automatically. Likewise, if the VISUAL variable is set to emacs, then emacs mode is used for editing.

If the VISUAL variable is not set, then the EDITOR variable is used.

In later versions of the AT&T Korn shell (such as 20100202) the recognized values have been expanded: the pattern *[Vv][Ii]* is recognized as a request for vi mode; the pattern *gmacs* results in gmacs mode; and the pattern *macs* results in emacs mode. (The only difference between emacs and gmacs mode is the handling of the ^T character.)

This means that using vim or gvim will now trigger vi mode – indeed, using almost any vi clone editor such as nvi or elvis will work with this method. This also means that the full path can be used, although this may have been true previously.

In bash however, this use of EDITOR and VISUAL is not available. However, since bash uses GNU readline, we can set up readline to use vi mode by default – and thus also affect all programs that use GNU readline besides.

Edit (or create) a file in your home directory called .inputrc and add this line to it:

set editing-mode vi

After this, any time you log in – or use anything else that uses GNU readline (such as CLISP for example) – you’ll automatically have vi mode editing. I can finally rest my fingers…

UNIX text pagers: more (or less)?

During your work on a system, you’ll often want to page through a document or some output. Aside from the pagers more and less and view, there really are no other ubiquitous options. There are other programs like w3m and pg, but they are not commonly found.

view has a lack of support for input from stdin (such as from a pipe or another command). This rules it out for lots of administration work. It is, however, ubiquitous, as it is part of vi. If you are used to vi, you may want to use view for looking at files (though not for output).

less is, as are many tools, found everywhere as one of the first things added – but almost never installed by default. The reason for this is unclear – other programs such as perl and ruby and tcl are also often found this way (that is, not installed by default but nearly always installed after the fact). If it is added that often, it should be part of the default install, one would think.

However, more is everywhere and is installed by default. The version of more installed on HP-UX appears to be much enhanced over the original more – a fact that is made apparent when you’ve gotten used to HP-UX more and try to use the Linux more. HP-UX more allows you to go back, to search, and other things that are not present in the Linux more.

Perhaps someone should copy the HP-UX more into Linux…. Hmmm…..

Why you should know vi

I won’t make any excuses; I love vi. Folks at The Register called vi Bill Joy’s greatest gift to mankind (who am I to argue?) However, being able to use vi well goes beyond whether you like it or not.

Why should you know vi (well)? For one thing, it is on every UNIX and Linux system. Emacs certainly isn’t, and neither are the other worthy competitors like pico, elm, nano, and others. None of these editors, good though they may be, are ubiquitous enough. In fact, every last one requires special installation on virtually every platform – that is, there are no default installations that include them.

Even vim is not ubiquitous – although it may be available for lots of environments, it is not necessarily installed by default. For a long time, I used vim in vi-compatible mode for just this reason. (My favorite vim-specific idea? :set nowrap).

Vi has an interesting history. Vi was written by Bill Joy, starting with the basics of the em editor from George Coulouris of Queen Mary College, University of London. Bill wrote vi to be able to work at 300 baud (as he says, that’s all he had and the fellows at MIT doing EMACS had the equivalent of fiber for that day and age). UNIX Review did an interview with Bill in August of 1984.

The original vi is now available under a BSD license. In contrast to EMACS and vim, both of which number in the multi-megabytes, vi was 160k on the i386.

So what editor does Bill use? ed.

UPDATE: Eric Raymond in his book The Art of UNIX Programming (also available online) has a very interesting analysis in Chapter 11 of the complexity and contrast (and psychology) between EMACS and vi.

Text Editors

Over at Hoff’s Blog, he recently discussed some thoughts he had about text editors. However, it was in the comments where I learned why TECO is so unstable on OpenVMS for Itanium. You wouldn’t think that anything in a shipping product would regularly do the equivalent of dump core – not to mention something as old and tested as TECO – but it’s true. Apparently TECO (being the old and unkillable beast that it is) wasn’t rewritten or debugged for Itanium, but rather was put on top of an emulation layer and translation layer, which seems to cause stability issues.

Thus, if you want a stable TECO (and who doesn’t want a stable editor?) you are better off getting a version of TECO-C and compiling it or installing it onto OpenVMS rather then using EDIT/TECO.

Believe it or not – I learned more about TECO before I learned about OpenVMS. And even among OpenVMS people, the TECO users must seem to be antiquarians or eccentrics! I just like the idea of programming my text editor…. (so I’m a little strange…)

Of course, vim and other more current editors are also available – and there are EDT clones for other machines if your inclination leans that way.

PS: Talking of editors – do any of you remember a text editor called NEAT? I seem to remember liking it, but I haven’t seen it since the Univac 1100/80 was decommissioned at the local university (a long time ago). And have you tried googling for a NEAT editor? (ouch!)

A “new” file pager: view

I, like most people I know, adore the file pager less. However, for whatever inconceivable reason, new UNIX systems (Linux doesn’t count here!) virtually never come with less. So… what to do when less is missing?

HP-UX, for one, comes with more and pg. Everything comes with more – but once you’ve used less you’ll never want to use a standard more again. The pager pg really isn’t any better.

Is there a solution? Yes – view.

What is view? The program view is a file pager which is included on virtually all UNIX and Linux systems. The view program is available, for example, in Solaris 9, HP-UX 11i v2, FreeBSD 6.2, Red Hat Linux 9, and more.

If you know vi, then you’ll know view. Why? Because view is actually vi in disguise, acting as a file pager with read-only access to the file.

The biggest drawback to view is that it does not handle stdin; that is, using view as the destination of a pipe gets very messy very fast (i.e., don’t do that!).

Apparently, vim handles this situation much better. Perhaps much better: there are ways to specify the use of vim with less keymappings, and to use view (i.e., vim) for general pager use! There are directions on how to make vim work as a man page viewer complete with syntax highlighting. Here is the quick and dirty instructions (for ksh):

export MANPAGER="col -b | view -c 'set ft=man nomod nolist' -"

For less key bindings, use (for ksh again):

export MANPAGER="col -b | /usr/share/vim/vim61/macros/less.sh -c 'set ft=man nomod nolist' -"

Be sure to use the right macro location for your version of vim. If you check out the original directions, be sure to read all of the comments: there are directions on how to properly configure the environment so reading man pages inside vim will work properly, and so that non-English locales can be handled properly, and more.

Next time you find yourself suffering without less – stop suffering through more and use view instead. You’ll be glad you did.