One reason ed(1) was a good editor back in the days of V7 Unix

April 18, 2019

It is common to describe ed(1) as being line oriented, as opposed to screen oriented editors like vi. This is completely accurate but it is perhaps not a complete enough description for today, because ed is line oriented in a way that is now uncommon. After all, you could say that your shell is line oriented too, and very few people use shells that work and feel the same way ed does.

The surface difference between most people's shells and ed is that most people's shells have some version of cursor based interactive editing. The deeper difference is that this requires the shell to run in character by character TTY input mode, also called raw mode. By contrast, ed runs in what Unix usually calls cooked mode, where it reads whole lines from the kernel and the kernel handles things like backspace. All of ed's commands are designed so that they work in this line focused way (including being terminated by the end of the line), and as a whole ed's interface makes this whole line input approach natural. In fact I think ed makes it so natural that it's hard to think of things as being any other way. Ed was designed for line at a time input, not just to not be screen oriented.

(This was carefully preserved in UofT ed's very clever zap command, which let you modify a line by writing out the modifications on a new line beneath the original.)

This input mode difference is not very important today, but in the days of V7 and serial terminals it made a real difference. In cooked mode, V7 ran very little code when you entered each character; almost everything was deferred until it could be processed in bulk by the kernel, and then handed to ed all in a single line which ed could also process all at once. A version of ed that tried to work in raw mode would have been much more resource intensive, even if it still operated on single lines at a time.

(If you want to imagine such a version of ed, think about how a typical readline-enabled Unix shell can move back and forth through your command history while only displaying a single line. Now augment that sort of interface with a way of issuing vi-like bulk editing commands.)

This is part of why I feel that ed(1) was once a good editor (cf). Ed is carefully adapted for the environment of early Unixes, which ran on small and slow machines with limited memory (which led to ed not holding the file it's editing in memory). Part of that adaptation is being an editor that worked with the system, not against it, and on V7 Unix that meant working in cooked mode instead of raw mode.

(Vi appeared on more powerful, more capable machines; I believe it was first written when BSD Unix was running on Vaxes.)

Update: I'm wrong in part about how V7 ed works; see the comment from frankg. V7 ed runs in cooked mode but it reads input from the kernel a character at a time, instead of in large blocks.

Comments on this page:

By frankg at 2019-04-19 01:45:57:

"where it reads whole lines"

I had to pull up my source because that did not sound like the way Ken writes code to me and it's not quite right. It's correct in no stty call is made to set raw mode but all terminal IO is done with unbuffered single char reads. This is from v6 but v7 is basically the same.

       if (read(0, &lastc, 1) <= 0)
               return(lastc = EOF);

Reading, writing files, and some other bits work with blocks in v6.

By v7 getline had been introduced for some operations. It was used for file I/O, joins, and moves. It's not the standard getline yet and ed has it's own buffering. Terminal I/O still used single char reads which adds characters to an array called linebuf. The block and single char I/O use the same linebuf so without following the code it can be difficult to determine how linebuf is being used.

I looked at the code because I was surprised it used cooked mode and indeed it does. It should have been obvious on old systems without a curses library properly handling backspace and erase would best be left up to the system.

For those interested in learning ed the book Ed Mastery by Michael Lucas is great. if you used ed on systems before vi existed you can stare with wonder at a book dedicated to ed like I did when I first saw it.

Written on 18 April 2019.
« A pattern for dealing with missing metrics in Prometheus in simple cases
Links: A Practitioner's Guide to System Dashboard Design (with a bonus) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Apr 18 23:25:56 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.