ReadKey like Function in C

[Karl Botts]

>**HOWEVER**, support for control of buffering is implementation-defined,
>and in fact I don't know of any system on which this works now.

There is another problem with mapping the MSDOS kbhit()-getch() functions
into the world of terminals which has not been discussed in this
discussion.  On the PC, all keys produce a single "scancode" (yes, I know
that sometimes it is one byte and sometimes it is two with the first being
zero, but it is always a single unambiguous code.)  This means that the
keyboard driver always knows whether a key has been hit or not.
	On most systems which support terminals, notably Unix, all the extra
keys besides the ascii keys produce escape sequences, which always start
with ascii ESC (0x1b).  The "Escape" key produces just a single ESC.  This
means that, whenever a keyboard driver sees an ESC it can't know whether
the ESC is from the Escape key or is the first char of an escape sequence.
If the input were coming from somewhere besides the keyboard, the driver
could do a lookahead to see if the next byte is part of a legal escape
sequence, and act accordingly.  But you can't lookahead at a keyboard
stream -- if the user has hit the Escape and refuses to hit another until
the keyboard driver reacts, the keyboard driver and the user are
deadlocked.
	There is no theoretical way out of this dilemma -- it is well known that
if one string in an accepting set is an initial substring of another, there
is no way to disambiguate without lookahead, except to make a rule that the
initial string is always recognized, which means that the longer string
never is.  This is why all the chars used for escape sequences in Unix
tools (mainly "\", but also, say "$" in "make", as well as others) must be
represented by themselves included twice.  The Escape key should issue
_two_ ESC bytes -- but it doesn't.
	The only way to deal with this is to wait for awhile -- typically 1/3 or
1/2 second -- when an ESC is seen, and return the ESC if no other byte comes
along.  But this is inevitably machine dependent, doesn't work worth a damn
over various kinds of wires, and so forth.  Because of the ambiguity a
kbhit() routine under Unix that tried to return a representation of an
entire keystroke would have to have this stuff built into it.  But making a
kbhit() routine that only returns keyboard bytes doesn't accomplish
anything -- it leaves the programmer still with the same problem.
	I have no solution for this.
could never map