13 Sep
2016
13 Sep
'16
3:53 a.m.
Doug McIlroy <doug(a)cs.dartmouth.edu> wrote:
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....
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
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.)