Simple question.

[Steve Summit]

In article <1991May1.222946.1281 at ux1.cso.uiuc.edu> phil at ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes:
>henry at zoo.toronto.edu (Henry Spencer) writes:
>>Note:  "on any sane system".  The fact is, this is an operating-system
>>question, not a C question.  C provides no standard way to do it.  This
>>question should be asked in some operating-system-specific group, like
>>comp.os.msdos.programmer.  Looking at comp.lang.c's Frequently Asked
>>Questions list might also be fruitful, since this is an FAQ.
>
>It is UNFORTUNATE that this is an OS question.  It really SHOULD be a C
>question.  There SHOULD be a standard way to specify "I don't want the
>input echoed".  Of course there are some limitations; some OS's don't make
>this easy or even possible.  But at least there should be a standard way
>to target it.

Since you ignored Henry's advice, and even though the full list
was posted less than 24 hours ago, I'm going to break my usual
policy and repost the relevant FAQ list answer, since this
complaint keeps coming up:

70.  How can I read a single character from the keyboard without waiting
     for a newline?

A:   Contrary to popular belief and many people's wishes, this is not a
     C-related question.  The delivery of characters from a "keyboard"
     to a C program is a function of the operating system in use, and
     cannot be standardized by the C language.  Some versions of curses
     have a cbreak() function which does what you want.  Under UNIX, use
     ioctl...

     Beware that some operating systems make this sort of thing
     impossible, because character collection into input lines is
     done by peripheral processors not under direct control of
     the CPU running your program.

Now, everybody who insists that the C standard should address
this issue, think a minute:

     1.	There were some moderately intelligent (free clue: this
	is a deliberate understatement) people serving on X3J11.
	They were not unaware of people's wishes in this regard.
	If they declined to specify anything, they probably had
	excellent reasons for doing so.  Virtually all operating
	system interface issues were deliberately deferred to the
	Posix committee, P1003.

     2.	Although some standards are written with varying degrees
	of compliance, X3.159 isn't one of them.  X3J11 had it as
	a high priority to assure that the Standard would be
	widely realizable.  Therefore, they simply could not
	specify things which were known not to be implementable
	on some systems.

     3.	*IF* a C language standard were to cover what we might as
	well call "terminal driver interactions," it could do so
	in only the most basic and simpleminded way.  It would
	likely provide a way to turn echoing off, and to provide
	for character-at-a-time input.  While this would shut the
	current crop of complainers up, and allow all sorts of
	little demonstration programs to be written, that's all
	it would do.  "Real" programs that play with the terminal
	driver ("visual" user interfaces, serial port or "modem"
	programs, etc.) need to know more and to have more
	control, at a level that only a full operating system
	standard, such as Posix, can specify.  (Terminal drivers
	are notorious for being overladen with features and still
	not providing what some programs think they need.)

     4.	Another important aspect of X3J11's charter was to
	standardize existing practice.  Whenever possible, they
	refrained from inventing new features or library
	routines.  (Their departures from this rule have
	invariably been the most hotly contested parts of the
	Standard.)  There is, however, no prior art for terminal
	driver control at the library ("chapter 3") level.  (That
	there is no prior art is not terribly surprising, if you
	understand point 3).  With the exception of curses, the
	only prior art in this area is ioctl, which is a system
	call ("chapter 2"), and which is therefore in P1003's
	baliwick, and which in any case is not the simple sort of
	mechanism people want.

     5.	There are all sorts of equivalent operating system
	dependencies which the C standard (properly) does not
	address.  ANSI C doesn't tell you how to backspace raw
	magtape, or format disks, or set baud rates, or set file
	modification times, or modify the environment.  Control
	over echoing and canonical mode processing only seems
	more important because it comes up so often.  But a good
	standard contains features because they belong there, not
	merely because they would be convenient or expedient.

To be sure, it would be very nice if there were a semistandard
library available which provided operating-system-independent
interfaces to simple functions such as echo and character-at-a-
time processing.  Peter da Silva (I think) makes this suggestion
from time to time, and may already have collected such a set of
routines; he'll probably post something now that this thread has
come up Yet Again.  (I put together a trivial terminal interface
library last March, to prove a point; it got no response.)  Note,
once again, that some versions of curses ALREADY PROVIDE THIS, in
the form of such functions as noecho() and cbreak().  (curses is,
in fact, exactly the sort of widely implemented, more-than-a-
language and less-than-an-operating-system library that people
are asking for, though for this question it provides more than is
necessary.)

If you'd like standardized control over the terminal driver, this
is the wrong place to be asking for it.  Like it or not, right or
wrong, the C standard does not address this issue, and it's not
going to address it for at least ten years (not that the next
version is likely to address it, either).  Blame the operating
system developers for having come up with such a welter of
mechanisms over the years, or the Posix committee for not having
come up with something easier to understand and use.  But please
don't blame C -- it's beating a dead horse at this point.

                                            Steve Summit
                                            scs at adam.mit.edu