Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> > Interesting, but then nobody did run a modern shell on one of these machines or
> > everybody did type slowly, so the character lossage problem did not occur.
>
> I'm afraid I don't get the point, apparently something about the
> relative performance of stream- and non-stream tty drivers. How
> do shells get into the act? And didn't uucp, which was certainly
> not a slow typist, appear like any dial-up connection and thus
> use /dev/ttyxx? (I cannot recollect, though, when dial-up uucp
> finally ceased.)

In 1982, I created a conceptional implementation and in 1984, I integrated a
cursor editable history into my shell.

As a result, this shell needed to switch the tty between raw and cooked mode.
With the traditional UNIX tty driver, this was no problem, but with the unfixed
AT&T strams based tty driver, this causes character loss.

With such a shell, the conceptional bug in the original AT&T streams caused
character loss when you type fast while the last command is going to terminate
and the shell takes the input while switching the tty into raw mode.

With the fix from Sun from around 1989, there is a new streams message that
informs the lower side of the stream about how many characters re going to be
read in raw mode. This permits to keep the other caracters in the edit buffer
and avoids the character loss seen with the original AT&T streams driver
concept.

All modern shells use such an integrated history editor....