Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Keyboard support in C (was Re: making charact
Message-ID: <10530@dog.ee.lbl.gov>
Date: 3 Mar 91 06:54:45 GMT
References: <1991Feb23.170142.538@ux1.cso.uiuc.edu> <15302@smoke.brl.mil> <14542@ganymede.inmos.co.uk> <1213@airs.UUCP> <568@coatimundi.cs.arizona.edu>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 25
X-Local-Date: Sat, 2 Mar 91 22:54:45 PST

In article <568@coatimundi.cs.arizona.edu> gmt@cs.arizona.edu
(Gregg Townsend) writes, in regard to a C library implementation
in which `unbuffered' stdio streams that talk to `terminals'
>>returns single characters without waiting for a carriage return
writes:

>Good ...  The ANSI spec, of necessity, is loose enough to allow other
>interpretations including doing nothing, and as far as I know that's
>the easy path that's been chosen by all Unix vendors.  (It's tricky
>to do "right", by which I mean ensuring that the tty modes aren't
>changed permanently.)

I agree that it is valid, but not that it is necessarily good.  I
contend that it is *impossible* to do `right', at least on some systems
(such as the ones I tend to use), simply because the definition of
`right' changes dramatically from application to application.  No
matter which definition you (or even I) choose as `right', it will
turn out to be wrong for something else.

(This is why the tty interfaces on Unix boxes are so complicated.  Perhaps
not all of the complexity is needed, but as yet, no one has figured out
how to get rid of it.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov