dumber terminal device drivers // DG AOS does it right

[John Gilmore]

I heartily agree with the guy who said if you're smartening the Unix
tty interface, look at how DG did it in AOS.  Not only did they make it
better and more featureful, they cleaned it up a lot too.  A simple
example:  on Unix if you read() 512 chars from a terminal you get up to
the next terminator.  You can't get that behaviour from a file.  AOS
lets you open any file or device for "data-sensitive" reads as well as
raw character count reads.  (And if you open a terminal for raw char
count reads, it waits until you type that many chars!  Now if only Unix
would do that...) Of course you can set the delimiter table (256 bit
table) and the default is reasonable (CR, NL, and suchlike).  You can
specify data sensitive/char count/various other options in each read()
call to override the way you open()ed it, if you like.

All of the above is independent of the "screenedit read" interface
described by the preceding message.  This facility adds a standard
interface for editing input lines, kinda like Unix cooked mode but
(important!) it knows about cursor positioning, insertion, and
deletion, so you don't have to retype the whole line to fix a typo in
the first word.  You'd be amazed at the difference.  (Some DG
expatriates who moved to Microsoft hacked a Bourne Shell that did
screenedit reads, probably in cbreak or raw mode or something.  I don't
know if it ever got put in their kernel, or released as a product.)

Note that the kernel need not know anything about escape sequences to
position the cursor within a single line (use BS or the next char on
the line), insert (repaint to the right) or delete (ditto).  Updating
speed is not a problem for typical input lines on hardwired terminals,
and if you're on a 300 baud line, you don't have to use the screenedit
features now do you?