Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: ReadKey like Function in C
Message-ID: <13656@bloom-beacon.MIT.EDU>
Date: 20 Aug 89 05:22:57 GMT
References: <148@trigon.UUCP> <225800206@uxe.cso.uiuc.edu> <3180@scolex.sco.COM> <3802@buengc.BU.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 26

In article <3802@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
>What I want to know is, how does EDT work, if VMS can't handle
>character-at-a-time devices.

Someone was mistaken when they implied that VMS cannot do
character-at-a-time input.  In fact, I know of at least three
ways to do it (for terminals):

     1.	with a SETMODE $QIO, analogous to CRMOD (there's also one
	like RAW)
     2.	with a per-function modifier on an individual READ $QIO
     3.	by doing the $QIO equivalent of read(fd, &c, 1)

Number 3 was a surprise.  It might be a bug; I don't know if it's
documented.  It came up when a colleague (Hi, Phil!) ported ed
to VMS using a Unix I/O emulation package I had written -- he
complained that for some reason he couldn't do input line editing
while in ed.  It turns out that ed does reads of 1 from standard
input.  I believe this dates to a very old version of Unix when
it was important to do so to avoid reading past a !, the
characters following which had to be left in some input buffer
for the shell to read during a shell escape.  This is no longer
appropriate for comp.lang.c, but belongs in comp.unix.ancient.history...

                                            Steve Summit
                                            scs@adam.pika.mit.edu