Commanding Standards

A few bits trickled through the Ethernet forming bytes, which coalesced into words,then sentences in a recent e-mail addressed to me. That in itself would not be unusual,except that this particular e-mail ruined a fishing trip for me. It wasn't the sender'sfault that it arrived after my last daily e-mail check, or that I happened to check e-mailat four a.m. before leaving for a day's fishing. It could be my fault for writing a recentcolumn about the history of shells and command line editing mechanisms, but since I don'ttake blame well, I think not.

Let's suppose then, that the fault lies within the basic principles of UNIX. To seehow, we will start with the email:

My only question about ksh and csh and even tcsh is: Why can't the command lineactually work in the simplistic way everything else does? Such as: left arrow goes left,delete (or backspace) works anywhere I place the cursor using the lt/rt arrow and I canchoose insert or overstrike at that location via a switch key (like Insert), if necessary.In addition, up-arrow should always return previous command lines (as it does in tcsh andDEC's VMS and IBM's OS/400).

When I first used ksh in 1993, I could not believe that these OBVIOUS standardswere not used, and I'm still amazed. Can you please quickly explain: (a) What do I get outof using editor commands instead of the obvious overstrike/insert method above on thecommand line (b) Why are we the only ones complaining about this kind of stuff?

-- Robert from
upstate New York

Robert, you must first remember that UNIX spent much of its youth hanging aroundcollege campuses. Campuses are those places where you can get a degree for spending acouple years of your life writing a paper that answers a rhetorical question.

Come to think of it, I bet someone could write a thesis based on your e-mail. So, inthe spirit of things collegiate, I'll throw out some thoughts based on your rhetoricalquestion, instead of going fishing. I hate it when something peaks my interest.

NO WHY. ONLY DO.

To start with, UNIX has seemingly always tried to be everything for everyone. Keep thatin mind, and lots of 'why' type questions disappear. For example, in the early days, you'doften find many different types of teletypes attached to a single box (whatever was lyingaround). When terminals came out, they basically emulated teletypes (often called glassteletypes) which means that they were acting like a printer with an infinite paper supply.

Later still, smart terminals came out, from many different companies, which actuallyhad the ability to move the cursor around the screen, and replace characters beingdisplayed without completely redrawing the screen. What an improvement! But --there isalways a but -- and in this case it is that different manufacturers used different controlsequences for the same screen functionality.

In steps Bill Joy, one of the early UNIX wizards (yes, at Berkeley). For those notaware of his list of accomplishments, it includes writing the vi editor circa 1970 (forwhich you might throw money, or eggs, depending on your fondness for vi). Since vi was ascreen editor, it made heavy use of screen controls (being able to see changes to text asyou made them was leading edge stuff back then ).

A VI-ABLE SOLUTION?

It was first written for a Lear Siegler terminal, which I suppose most people readingthis column have never heard of, much less seen. In order to get vi working on otherterminals, it had to be smart about understanding control sequences. Joy had some choices.He could have started making vi understand various terminals, but that required periodicupdates as new terminals were developed. And, we know that it's against UNIX culture toupdate programs, so that was deemed a bad idea.

The idea Joy came up with was a great solution. He wrote vi to use generic screencontrol commands, which were then looked up in a database and translated to control codesand settings for the terminal type being used. Termcap or terminfo databases storethis information to this day.

Which terminal type you're using is still important to most programs that perform anyterminal screen operations. As we all know, the terminal type is passed to programs viathe contents of the TERM variable. The amazing thing is that with our current tremendouscomputing power and graphics capabilities, such as bit-mapped displays, we're still usingit to emulate ancient teletypes.

Getting back to your questions (finally), why didn't those that wrote the UNIX shellsfollow the common conventions of VMS, MS-DOS and other command parsers?

I don't know.

As far as the up arrow returning previous commands, most shells do, if configuredcorrectly. For example, the korn shell will indeed return the previous command, and allowthe left/right arrow keys to be used for simple editing if you use emacs command editingmode. Most tcsh programs use emacs mode by default, but if yours is set to vi mode, usethe bindkey command to change to emacs.

TURN ON, TUNE UP

Turn on emacs command editing style in the korn shell with the set -o emacs command.Using set -o vi in a korn shell turns on vi mode, where you have to use the vi command formoving up a line to get the previous command. The bash shell (Developed by the FreeSoftware Foundation) also has both emacs, and vi mode command line editing.

You should spot a trend here. The UNIX shells that offer command line editingcapabilities (ksh, tcsh, bash) all do so using editors, rather than programmed infunctionality. There are several advantages. First, those editors already have theterminal capabilities built into them. This means you can telnet, rlogin, remote dial-inand remote display to your heart's content, from almost any terminal type, and things willstill work reasonably well, so long as your TERM variable is set correctly. A ratherelegant solution.

Another important benefit is that you get more complex capabilities without learninganother set of commands. If you already know how to delete a previous word in yourfavorite editor, you can use that capability on the command line by pressing <esc>dbin vi mode editing, or <esc>b in emacs mode. You can copy and paste, or even useabbreviations or macros. Then again, most of us do not use command line editing to thislevel, but we could.

Now, why are we the only ones that care? Actually, it's only you. I'm going fishing.

-- Fred has had great success hauling in the really big ones lately byusing korn shells as bait.