ReadKey like Function in C

[Doug Gwyn]

In article <19095 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>What does `kbhit()' mean when stdin is a socket?  How about in a VMS
>batch job?
>What does getch() do at end of file?
>Before you settle on <X> as a standard across hundreds of systems, be sure
><X> can well-defined everywhere.

Although I agree with the sentiment, especially since I work in an
environment where it is not always clear what is meant by a "terminal",
but that's not a fatal objection.  The C Standard already allows
implementations to have some sort of notion of "terminal" and to do
certain operations slightly differently when a "terminal" is involved.
So far, this seems to be limited to whether or not output is fully or
just line buffered, which is a relatively unimportant matter for most
applications programs.  I personally prefer to explicitly fflush()
output when I want to be sure that it's seen before the program
proceeds.

Terminal input is a more difficult matter to deal with than output
buffering, because of the necessity to deal with mode switches (from
input cnanonicalizing to non-canonicalizing) in many environments.
The reason input canonicalization is done is of course to allow humans
to correct typical typing errors before their input is received by
applications; otherwise every application would have to take care of
it, which is obviously poor software design.

kbhit() and getch() are a poor model for such an environment.