Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!math.fu-berlin.de!fauern!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX bashing (actually cooked vs raw or cbreak mode)
Message-ID: <1093@mwtech.UUCP>
Date: 12 Apr 91 13:55:05 GMT
References: <3419@unisoft.UUCP> <5980071@hpfcdc.HP.COM> <3446@unisoft.UUCP> <15621@smoke.brl.mil> <70319@brunix.UUCP> <3478@unisoft.UUCP> <
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 51

In article <1991Apr10.192226.24909@world.std.com> geoff@world.std.com (Geoff Collyer) writes:
>The last thing I want is each application having a
>different idea of what I have to type to erase input (for example).
>`Gee, now I'm in emacs, so I have to type control-A control-K to erase my
>line.' Ugh.  One of the great wins of Unix is that it lets the *user*
>make such choices, not J. Random Losing Application (unless it switches
>to cbreak mode, which is becoming distressingly common).

The idea sounds right, but the implementation is too poor for todays
hardware. One of the biggest problems in this area is that the level
to which a "user" can configure the kernel (more exactly the TTY-driver)
is at the level of 20 years old hard-copy terminals, dumb "glass ttys" at
best.

Look, there are still numerous possibilities to specify delays, tab
expansion and things I hardly ever need with todays hardware, but tell
me how I can make the "cursor right" key (which happens to send three
characters, I know, that's something botched too but quite another topic)
be my "erase" key? Further, how can I edit the beginning of the line
without deleting from the end?

The reason that so many applications switch to cbreak mode is just
that too *few* is done in the device driver or line discipline.
(I'm sure if slightly "intelligent" CRT-displays were commonly used
at the time Thompson and Ritchie started with UNIX, the situation
were better ...)

>reason that cooked mode is a win (fewer context switches being the other
>obvious one)

The cost for context switches is not extremly high on modern hardware, so
that one should not worry too much about this. Well, I don't have exact
numbers - does anyone else? Let's assume 5 msec and someone who types
5 characters per second - this will cost 2.5 % CPU cycles. OK, if there
are 10 to twenty users this would become more considerable, but often
the user will sit there watching the output (and think or drink coffee or
whatever) so that the *average* typing rate is probably much below my guess.
(Further, the fact that so many programs today *do* switch to cbreak mode
can be taken as indication that context switches aren't so much of a problem
for modern hardware :-). Do you notice a degradation in performance when
many users are working with vi?)

>and that shell globbing is a win: they are done centrally,
>by one piece of code, so they work uniformly and all applications and
>users benefit.  (Yeah, we know about "restore *".)

I see you know :-) ... and also processing of command-line options for
programs (or at least some preprocessing) should have been done centrally
from the beginning on ...
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83