Xref: utzoo comp.std.c:1639 comp.lang.c:21708
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!rjf001!hpftc!teemc!rphroy!edsews!uunet!tut.cis.ohio-state.edu!cica!iuvax!purdue!bu-cs!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: ReadKey like Function in C
Message-ID: <13446@bloom-beacon.MIT.EDU>
Date: 12 Aug 89 20:51:58 GMT
References: <148@trigon.UUCP> <207600029@s.cs.uiuc.edu> <941@lakesys.UUCP> <21175@cup.portal.com> <3705@buengc.BU.EDU> <10712@smoke.BRL.MIL>
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 56

In article <3705@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
>How about if someone begs with the ANSI committee to have its
>implementation as a standard function required for compliance?

In article <10712@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>Not only is it too late, but I think it was proposed and justly was
>awarded a "VE" stock response code, meaning:  The Standard must
>accommodate a variety of environments.

Doug is correct, but the astonishing frequency with which this
question arises (I think it's been asked on comp.lang.c three
times in the past week alone) indicates that the opportunity is
ripe for some kind of informal, community-"standard" solution.
(Or did someone try this already?)

One difficulty is whether the interface should be a "getkey"
routine or a set of mode-setting functions.  A straightforward
getkey implementation on Unix would suffer at least three system
call overheads per character read.  Mode setting, though hewing
to the Unix ioctl tradition, might be distasteful to MS-DOS
aficionadoes who appreciate the utility of getch() (and, on a
related note, kbhit()).  (The presence of these two simple, oft-
needed routines might be said to be one thing which DOS does
right, although it's achieved with the introduction of a bizarre
dichotomy between "Console I/O" and stdio.)

A useful approach (combining the worst of both approaches) would
accommodate mode setting _and_ a separate getkey routine:

	setkeymode(CHARATATIME);
	/* repeated calls to */ getkey();
	setkeymode(CANONICAL);

On Unix, setkeymode would play the usual games with ioctls
(V7, SYSV, or POSIX flavors), and getkey would map to getchar.
On MS-DOS, setkeymode would be a no-op and getkey would map to
getch.  On VMS, either approach could be used (there's a per-read
QIO function modifier to disable canonical processing, as well as
mode-setting QIO's.)  On other systems the scheme might be
unimplementable, but that's what I mean by an informal, community
"standard," as opposed to a mandatory part of the pANS.

If there's interest, I could post versions for the three systems
mentioned above (I'd only be able to test the V7/BSD Unix
variants), but first we have to have a long debate about what the
routines should be called...

                                            Steve Summit
                                            scs@adam.pika.mit.edu

P.S. It occurs to me that, whenever this question is asked,
     someone points out that the curses package provides a semi-
     standard means of doing character-at-a-time input, which
     could be used independently of curses' screen management
     features.  I suppose the sequence would be crmode();
     getch(); nocrmode();.  ("getch" -- what a coincidence.)