moshkovi@ecn.purdue.edu (Gennady Moshkovich) (09/01/90)
Hi C gurus. My question is pretty much simple. In FORTRAN we have format specifications nX and Tn, which allow either skip n chracters or start typing of the next field from the n'th postion. respectively. Is there any similar field modifiers for printf() in C ? -- _______________________________________________________________________ | Gennady Moshkovich GGGG M M | | G MM MM | | 317-495-5608 G M M M M |#include <stdprvrb.h> | moshkovi@en.ecn.purdue.edu G G M M M | | GGGG M M | |_______________________________________________|______________________
cfiddyme@gara.une.oz.au (Kith Kanan) (04/29/91)
Could someone please tell me if it is possible to read a string with
scanf() and not have the string printed on the screen.
Thanks.
Chris.matteo@ghost.unimi.it (Matteo Gelosa) (04/29/91)
cfiddyme@gara.une.oz.au (Kith Kanan) writes: > Could someone please tell me if it is possible to read a string with > scanf() and not have the string printed on the screen. First: What do you mean with "not have the string printed on the screen"...??? scanf() doesn't print anything aywhere at all. It simply scan standard input or a file opened with fopen() looking for the first object that match the format argument according to format rules. So if you do something like char buffer[64]; scanf("%s", buffer); it will read from standard input the first character sequence between any kind of blanks (' ', '\t', '\n'...) without printing anything at all!!. Probably you mean how you can inserting characters from keyboard without echoing them on terminal. Lookup ioctl(2) and termio manuals you can get a lot of information about tty-s setting up. Matteo Gelosa. matteo@ghost.unimi.it
ron@well.sf.ca.us (Ronald Hayden) (05/01/91)
cfiddyme@gara.une.oz.au (Kith Kanan) writes: > Could someone please tell me if it is possible to read a string with > scanf() and not have the string printed on the screen. > Thanks. > Chris. scanf() will always echo the characters, but getchar() won't. If you're receiving more than one character, though, you'll have to call getchar() multiple times, as it only processes a character at a time.
henry@zoo.toronto.edu (Henry Spencer) (05/02/91)
In article <24528@well.sf.ca.us> ron@well.sf.ca.us (Ronald Hayden) writes: >> Could someone please tell me if it is possible to read a string with >> scanf() and not have the string printed on the screen. > >scanf() will always echo the characters, but getchar() won't... Wrong; on any sane system, scanf() and getchar() use precisely the same machinery for getting characters, and both normally echo them. 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. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
rjohnson@shell.com (Roy Johnson) (05/02/91)
In article <24528@well.sf.ca.us> ron@well.sf.ca.us (Ronald Hayden) writes: cfiddyme@gara.une.oz.au (Kith Kanan) writes: > Could someone please tell me if it is possible to read a string with > scanf() and not have the string printed on the screen. > Thanks. > Chris. scanf() will always echo the characters, but getchar() won't. If you're receiving more than one character, though, you'll have to call getchar() multiple times, as it only processes a character at a time. This is really OS specific. Scanf does NOT echo characters, the OS does. See your appropriate OS manuals or newsgroup for details. The answer to the original question is "Yes, it is probably possible." -- =============== !You!can't!get!here!from!there!rjohnson =============== Feel free to correct me, but don't preface your correction with "BZZT!" Roy Johnson, Shell Development Company
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/02/91)
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. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
scs@adam.mit.edu (Steve Summit) (05/02/91)
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
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/03/91)
In article <24528@well.sf.ca.us>, ron@well.sf.ca.us (Ronald Hayden) writes: > cfiddyme@gara.une.oz.au (Kith Kanan) writes: > > Could someone please tell me if it is possible to read a string with > > scanf() and not have the string printed on the screen. > > Thanks. > > Chris. > scanf() will always echo the characters, but getchar() won't. If > you're receiving more than one character, though, you'll have to call > getchar() multiple times, as it only processes a character at a time. This is an operating-system-specific question. On the machines I normally use, the statement "scanf() will always echo the characters, but getchar() won't" is simply false. For example, when scanf() is reading from a file, nothing is echoed. More to the point, on UNIX machines, whether echoing is done or not is part of the state of the terminal driver, and has nothing to do with which stdio functions (if any) you are using. What you _really_ want to do is to find out about the "curses" package. "curses" comes with UNIX, the "curses" interface is available in VAX/VMS C, and there are several versions of "curses" for PCs, including a free one. Using curses: noecho(); scanw(format, args...); echo(); -- Bad things happen periodically, and they're going to happen to somebody. Why not you? -- John Allen Paulos.
shap@shasta.Stanford.EDU (shap) (05/07/91)
scanf shouldn't be echoing characters. Either you have a setting wrong and your terminal line is doing autoecho or your vendor screwed up.
mike@sojurn.UUCP (Mike Sangrey) (05/12/91)
In article <6131@gara.une.oz.au> cfiddyme@gara.une.oz.au (Kith Kanan) writes: > > Could someone please tell me if it is possible to read a string with > scanf() and not have the string printed on the screen. > Thanks. > Chris. Yes, it is possible. What? You want details ... You go first. -- | UUCP-stuff: devon!sojurn!mike | "It muddles me rather" | | Slow-stuff: 832 Strasburg Rd. | Winnie the Pooh | | Paradise, Pa. 17562 | with apologies to | | Fast-stuff: (717) 442-8959 | A. A. Milne |
dave@cs.arizona.edu (Dave Schaumann) (05/12/91)
>In article <6131@gara.une.oz.au> cfiddyme@gara.une.oz.au (Kith Kanan) writes: >> >> Could someone please tell me if it is possible to read a string with >> scanf() and not have the string printed on the screen. >> Thanks. >> Chris. Manipulating character echo on input is a system-specific thing. There is no provision in the C standard for turning off echo, or reading characters without hitting return, or many other useful but rather system specific things. I suggest you read your system manual, or re-ask your question in a machine specific group, or even (gasp!) ask someone at your local site. -- Dave Schaumann | There is no cause so right that one cannot find a fool dave@cs.arizona.edu | following it. - Niven's Law # 16