Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!haven!umd5!adm!smoke!gwyn From: gwyn@smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Echoing chars and input functions Message-ID: <8364@smoke.ARPA> Date: 20 Aug 88 19:48:50 GMT References: <8808160751.aa03016@SMOKE.BRL.MIL> <8349@smoke.ARPA> <2821@boulder.Colorado.EDU> <8354@smoke.ARPA> <64974@sun.uucp> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 30 In article <64974@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: -I think it is unfair to characterize OS's that don't echo as being -"deficient". LSC, in an attempt to provide to provide compatibility, -takes on the responsibility of creating a terminal-like window so stdio -functions will work as expected. If they really expect you to type "blind" in their emulated terminal window, I would surely call that deficient! In a scenario like this, part of the "OS" is being provided by the C run-time environment implementation. -I don't think it is reasonable to say -that the C environment need not be concerned about things such as echoing -because it is an OS problem when the host OS has no concept of a terminal. That's not what I said. I said it is not a problem to be addressed by the application code. LSC definitely should provide reasonable support for terminal-like input, including echoing and input line editing, in SOME part of their environment. It should not require special action by the typical application to get this. -All that I really want is some portable way to read interactive input -that looks roughly the same across implmentations of C. As long as -most implementations echo input fetched with getchar() and LSC doesn't -(and the OS can't) then this isn't possible. My complaint is that ANSI -doesn't do anything to solve the problem. "ANSI" is in no position to solve a design problem in the implementation of a particular product. You should nag the vendor to do a better job.