From: schily@schily.net (Joerg Schilling)
Subject: [TUHS] BSD/v8 TCP/IP
Date: Mon, 12 Sep 2016 23:53:45 +0200 [thread overview]
Message-ID: <57d723e9.8xNcmlVDu6NtFK0V%schily@schily.net> (raw)
In-Reply-To: <201609122139.u8CLdkQc043283@tahoe.cs.Dartmouth.EDU>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]
Doug McIlroy <doug at 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....
Jörg
--
EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
next prev parent reply other threads:[~2016-09-12 21:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-12 21:39 Doug McIlroy
2016-09-12 21:48 ` Dave Horsfall
2016-09-12 21:53 ` Joerg Schilling [this message]
2016-09-12 23:49 ` Dan Cross
2016-09-13 9:16 ` Joerg Schilling
2016-09-13 1:52 ` Lyndon Nerenberg
2016-09-13 2:37 ` Larry McVoy
2016-09-13 8:12 ` Brantley Coile
2016-09-13 9:29 ` Joerg Schilling
2016-09-13 14:35 ` Larry McVoy
-- strict thread matches above, loose matches on Subject: below --
2016-09-12 20:16 Doug McIlroy
2016-09-12 20:27 ` Larry McVoy
2016-09-12 20:36 ` Lyndon Nerenberg
2016-09-12 20:42 ` Joerg Schilling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57d723e9.8xNcmlVDu6NtFK0V%schily@schily.net \
--to=schily@schily.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).