Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!bloom-beacon!bloom-picayune.mit.edu!news From: scs@adam.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Re: Simple question. Message-ID: <1991May2.022124.11880@athena.mit.edu> Date: 2 May 91 02:21:24 GMT References: <24528@well.sf.ca.us> <1991May1.170311.18988@zoo.toronto.edu> <1991May1.222946.1281@ux1.cso.uiuc.edu> Sender: news@athena.mit.edu (News system) Reply-To: scs@adam.mit.edu Organization: Thermal Technologies, Cambridge, MA Lines: 118 In article <1991May1.222946.1281@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: >henry@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@adam.mit.edu