immi@trigon.UUCP (immi) (08/04/89)
Hello,
I am a real beginner in C but I'm looking for a Function that will only
read a single character from the keyboard, without confirming it with an
ENTER. Can anybody help me with this ?
Thanx
-Immanuel
--
Immanuel Bloch E-Mail: | Robinson Crusoe |
Trigon Chemie GmbH ..!uunet!unido!trigon!immi | was the only person |
6490 Schluechtern immi@trigon.UUCP | who got all his work |
West Germany | done by Friday |chris@mimsy.UUCP (Chris Torek) (08/07/89)
In article <148@trigon.UUCP> immi@trigon.UUCP (immi) writes: >I am a real beginner in C but I'm looking for a Function that will only >read a single character from the keyboard, without confirming it with an >ENTER. Can anybody help me with this ? Not in a C newsgroup, no. C runs on (among other things) the Univac 1100 series with input fed through Microdata concentrators, which do not hand input to the CPU until they see a line terminator. There is no way to read a single character from such a virtual card punch; the hardware simply does not allow it. (Actually, the Microdata can be reprogrammed, but your average computer center is not likely to let you do it.) Now, if you wanted a VMS-specific method, or a PrimeOS-specific method, or an MS-DOS specific method, or any other X-specific method, you could go ask in some newsgroup devoted to X. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bph@buengc.BU.EDU (Blair P. Houghton) (08/08/89)
In article <18919@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <148@trigon.UUCP> immi@trigon.UUCP (immi) writes: >>I am a real beginner in C but I'm looking for a Function that will only >>read a single character from the keyboard, without confirming it with an >>ENTER. Can anybody help me with this ? > >Not in a C newsgroup, no. C runs on (among other things) the Univac >1100 series with input fed through Microdata concentrators, which do Oh yeah... The Univac 1100 at UMCP. The only machine accessible for all undergrad engineering majors... All-nighters in the 24-hour room at Hornbake... Nothing but a line-editor, or a full-screen editor that makes you wish you had a line-editor... Thanks, Chris. --Blair "I need a bromo. :-*"
mccaugh@s.cs.uiuc.edu (08/09/89)
Wait a minute -- am I missing something here? Isn't conventional (Kernighan- Ritchie) C supoosed to be capable of system-calls to the operating-system, say, to switch I/O-mode from cooked to raw, thereby obviating the <CR> on char-input, then switching back when done?
chris@mimsy.UUCP (Chris Torek) (08/10/89)
In article <207600029@s.cs.uiuc.edu> mccaugh@s.cs.uiuc.edu writes: >Wait a minute -- am I missing something here? Isn't conventional (Kernighan- >Ritchie) C supoosed to be capable of system-calls to the operating-system, >say, to switch I/O-mode from cooked to raw, thereby obviating the <CR> on >char-input, then switching back when done? Assuming you have an operating system, and assuming it provides such a capability, yes. (As I mentioned, some Univac and IBM systems [on which C compilers do sometimes exist] think they are talking to card reader/punches and line printers, even if there is a graphics display terminal at the end of the virtual card punch. One winds up inventing horrible and baroque protocols so as to be able to interact with such machines.) At any rate, if the system exists and is capable, the question has changed. No longer is it `how do I read a single key in C': It has become `how do I make a system call from C to enable single key operation, or obtain a single keystroke, using FooBletchOS Version 91523.158.1.6.23.9.4-and-a-half'. And that question does not belong in a C newsgroup (or mailing list, for those without netnoise). (Incidentally, this is one of those things that seems to change with every variation of the system. Pick any two Unix machines; they probably do it differently. Even different releases of VMS do it differently.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
davef@lakesys.UUCP (Dave Fenske) (08/10/89)
In article <207600029@s.cs.uiuc.edu> mccaugh@s.cs.uiuc.edu writes: > > Wait a minute -- am I missing something here? Isn't conventional (Kernighan- > Ritchie) C supoosed to be capable of system-calls to the operating-system, > say, to switch I/O-mode from cooked to raw, thereby obviating the <CR> on > char-input, then switching back when done? Absolutely! You need only do the following: 1. do an "ioctl (n, TCGETA, &term) 2. modify some parameters, such as term.c_lflag &= ~(ICANON | ECHO) or whatever else you need 3. term.c_cc [VTIME] = some_value <- for timeout, if desired 4. term.c_cc [VMIN] = 1 <- satisfy read with 1 character 5. ioctl (m, TCSETA, &term) to reset the terminal 6. you can now do a read (n, &work, 10) You might need/want to reset the terminal, but these are the basic steps.
Tim_CDC_Roberts@cup.portal.com (08/11/89)
In article <941@lakesys.UUCP>, Dave Fenske writes: >In article <207600029@s.cs.uiuc.edu> mccaugh@s.cs.uiuc.edu writes: > > > > Wait a minute -- am I missing something here? Isn't conventional > > (Kernighan-Ritchie) C supoosed to be capable of system-calls to > > the operating-system, say, to switch I/O-mode from cooked to raw, > > thereby obviating the <CR> on char-input, then switching back when > > done? > >Absolutely! You need only do the following: > >1. do an "ioctl (n, TCGETA, &term) > (remainder deleted) Ah, but this is not a C solution, K&R or otherwise. It is a UNIX solution. Definitively, once again: THERE IS NO STANDARD, O.S.-TRANSPARENT METHOD OF READING A SINGLE KEYSTROKE WITHOUT A CR. Never has been, never will be. If the original questioner rephrases to: "How can I do a ReadKey in Microsoft C 5.0 on MS-DOS", THEN there is an answer. However, the question "How can I do a ReadKey in C?" has no correct unqualified answer. Tim_CDC_Roberts@cup.portal.com | Control Data... ...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.
darin@nova.laic.uucp (Darin Johnson) (08/11/89)
In article <941@lakesys.UUCP> davef@lakesys.UUCP (Dave Fenske) writes: > >1. do an "ioctl (n, TCGETA, &term) Hmmn, I get the following error when linking... %LINK-I-UDFSYM, IOCTL %LINK-W-USEUNDEF, undefined symbol IOCTL referenced in psect $CODE offset %X00000013 in module TEST file DSK5:[DARIN.TMP]TEST.OBJ;1 :-) Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.
daveh@marob.masa.com (Dave Hammond) (08/11/89)
In article <941@lakesys.UUCP> davef@lakesys.UUCP (Dave Fenske) writes: >In article <207600029@s.cs.uiuc.edu> mccaugh@s.cs.uiuc.edu writes: >> Wait a minute -- am I missing something here? Isn't conventional (Kernighan- >> Ritchie) C supoosed to be capable of system-calls to the operating-system >> [...] >Absolutely! You need only do the following: > >1. do an "ioctl (n, TCGETA, &term) >2. modify some parameters, such as > term.c_lflag &= ~(ICANON | ECHO) or whatever else you need >3. term.c_cc [VTIME] = some_value <- for timeout, if desired >4. term.c_cc [VMIN] = 1 <- satisfy read with 1 character >5. ioctl (m, TCSETA, &term) to reset the terminal >6. you can now do a read (n, &work, 10) True enough -- on ONE of the dozens of systems on which C compilers exist. Remember, the name of this newsgroup is NOT comp.lang.c.on.unix.system.v ! -- Dave Hammond daveh@marob.masa.com
jeffa@hpmwtd.HP.COM (Jeff Aguilera) (08/12/89)
> Absolutely! You need only do the following: > > 1. do an "ioctl (n, TCGETA, &term) > 2. modify some parameters, such as > term.c_lflag &= ~(ICANON | ECHO) or whatever else you need > 3. term.c_cc [VTIME] = some_value <- for timeout, if desired > 4. term.c_cc [VMIN] = 1 <- satisfy read with 1 character > 5. ioctl (m, TCSETA, &term) to reset the terminal > 6. you can now do a read (n, &work, 10) Close. If a timeout is specified, set term.c_cc[VMIN] = 0. Otherwise the timer is not started until receipt of the first character; i.e., the program can still wait forever.
scs@adam.pika.mit.edu (Steve Summit) (08/13/89)
In article <3705@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >How about if someone begs with the ANSI committee to have its >implementation as a standard function required for compliance? In article <10712@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Not only is it too late, but I think it was proposed and justly was >awarded a "VE" stock response code, meaning: The Standard must >accommodate a variety of environments. Doug is correct, but the astonishing frequency with which this question arises (I think it's been asked on comp.lang.c three times in the past week alone) indicates that the opportunity is ripe for some kind of informal, community-"standard" solution. (Or did someone try this already?) One difficulty is whether the interface should be a "getkey" routine or a set of mode-setting functions. A straightforward getkey implementation on Unix would suffer at least three system call overheads per character read. Mode setting, though hewing to the Unix ioctl tradition, might be distasteful to MS-DOS aficionadoes who appreciate the utility of getch() (and, on a related note, kbhit()). (The presence of these two simple, oft- needed routines might be said to be one thing which DOS does right, although it's achieved with the introduction of a bizarre dichotomy between "Console I/O" and stdio.) A useful approach (combining the worst of both approaches) would accommodate mode setting _and_ a separate getkey routine: setkeymode(CHARATATIME); /* repeated calls to */ getkey(); setkeymode(CANONICAL); On Unix, setkeymode would play the usual games with ioctls (V7, SYSV, or POSIX flavors), and getkey would map to getchar. On MS-DOS, setkeymode would be a no-op and getkey would map to getch. On VMS, either approach could be used (there's a per-read QIO function modifier to disable canonical processing, as well as mode-setting QIO's.) On other systems the scheme might be unimplementable, but that's what I mean by an informal, community "standard," as opposed to a mandatory part of the pANS. If there's interest, I could post versions for the three systems mentioned above (I'd only be able to test the V7/BSD Unix variants), but first we have to have a long debate about what the routines should be called... Steve Summit scs@adam.pika.mit.edu P.S. It occurs to me that, whenever this question is asked, someone points out that the curses package provides a semi- standard means of doing character-at-a-time input, which could be used independently of curses' screen management features. I suppose the sequence would be crmode(); getch(); nocrmode();. ("getch" -- what a coincidence.)
henry@utzoo.uucp (Henry Spencer) (08/13/89)
In article <13446@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >Doug is correct, but the astonishing frequency with which this >question arises (I think it's been asked on comp.lang.c three >times in the past week alone) indicates that the opportunity is >ripe for some kind of informal, community-"standard" solution. I strongly suggest that you read IEEE standard 1003.1, i.e. POSIX, before re-inventing the wheel pointlessly. POSIX compliance will be widespread in the very near future, so the POSIX approach will automatically be *far* more widespread than any "community 'standard'" approach. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
scs@adam.pika.mit.edu (Steve Summit) (08/13/89)
In article <13446@bloom-beacon.MIT.EDU> I wrote: >...the astonishing frequency with which this >question arises indicates that the opportunity is >ripe for some kind of informal, community-"standard" solution. In article <1989Aug13.004829.28322@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >I strongly suggest that you read IEEE standard 1003.1, i.e. POSIX, before >re-inventing the wheel pointlessly. POSIX compliance will be widespread >in the very near future, so the POSIX approach will automatically be >*far* more widespread than any "community 'standard'" approach. I agree (in fact I have a copy of 1003.1 right here on my desk) and I'll start using its facilities as soon as they become available on machines I use, but in the meantime, and for non-Unix systems such as VMS and MS-DOS, I'd like to have a carrot to toss to the people who keep asking for getch() and kbhit(), in a similar spirit to the getopt() routines which have been floating around for years. You're right, the time for a "community 'standard'" approach is not exactly ripe, but more like waning. Steve Summit scs@adam.pika.mit.edu
mcdonald@uxe.cso.uiuc.edu (08/14/89)
/* Written 11:05 pm Aug 12, 1989 by scs@adam.pika.mit.edu in uxe.cso.uiuc.edu:comp.lang.c */ In article <13446@bloom-beacon.MIT.EDU> scs@pika.mit.edu wrote: >...the astonishing frequency with which this >question arises indicates that the opportunity is >ripe for some kind of informal, community-"standard" solution. In article <1989Aug13.004829.28322@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >I strongly suggest that you read IEEE standard 1003.1, i.e. POSIX, before >re-inventing the wheel pointlessly. POSIX compliance will be widespread >in the very near future, so the POSIX approach will automatically be >*far* more widespread than any "community 'standard'" approach. Posix fooey!!!!!! Posix is a standard for one and only one OS, not a language standard. IT WILL BE OF ZERO repeat ZERO utility. Let's get this straight: FLAME ON!! FLAME ON!! FLAME ON!!! What is needed is a language standard, in the C standard, in the Fortran standard, in the Pascal standard, in the A.. (oops, that's already too big, besides it may already be there with the kitchen sink). Standardization on one OS is NOT what is needed!!!!!!! For example it ALREADY is standard on MSDOS. The language standards need some construct equivalent to what getch() and kbhit() do on MSDOS. This MUST be IN THE LANGUAGE STANDARD!!!!!! It MUST MUST MUST be there (do you begin to feel the flame???) to FORCE vendors to, if necessary, ************************************ FIX THEIR OPERATING SYSTEMS SO IT WILL WORK ************************************ Flame off. A mode flag to make getchar behave like getch would be OK, but some new function like kbhit() would still be needed. The exact name of the functions is of course not really important, except that getch is already common. Please note that there are things in the new Fortran standard that will require some vendors to fix their OS's - like long global names. I do not speak for any vendor, merely as a frustrated user. Doug McDonald
davidsen@sungod.crd.ge.com (ody) (08/15/89)
I agree that these should be part of the standard! Anyone who has
written a (more or less) portable program knows the joy of setting raw
mode one way for SysV, another for BSD, using raw read calls in CP/M and
MS-DOS, a calling sys$read_raw$some_long_name in VMS. It gets worse as
you go to TOPS, PRIMOS, etc.
One of the constraints of X3J11 was to "codify existing practice," and
I hope that this will continue in the next C version. Therefore, since
kbhit() and getch() are probably the widest spread, I would suggest that
the MS-DOS haters would still like to adopt this convention, since it
would simplify porting programs to other operating systems.
bill davidsen (davidsen@crdos1.crd.GE.COM)
{uunet | philabs}!crdgw1!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mechris@mimsy.UUCP (Chris Torek) (08/15/89)
In article <1677@crdgw1.crd.ge.com> davidsen@sungod.crd.ge.com (ody) writes: > One of the constraints of X3J11 was to "codify existing practice," and >I hope that this will continue in the next C version. Therefore, since >kbhit() and getch() are probably the widest spread, I would suggest that >the MS-DOS haters would still like to adopt this convention, since it >would simplify porting programs to other operating systems. 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. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
henry@utzoo.uucp (Henry Spencer) (08/15/89)
In article <225800206@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>I strongly suggest that you read IEEE standard 1003.1, i.e. POSIX, before >>re-inventing the wheel pointlessly. POSIX compliance will be widespread >>in the very near future... > >Posix fooey!!!!!! Posix is a standard for one and only one OS, not >a language standard. IT WILL BE OF ZERO repeat ZERO utility... Nonsense. While POSIX is a standard for one operating system, many people will be trying hard to make their own pet system POSIX-compliant, or as POSIX-compliant as possible. (I would expect OS/2 to provide POSIX compliance at some point, for example.) The point is, the POSIX way of doing things is the closest there is to an OS-independent standard; your odds of finding it on your new system from XYZ Vaporboxes Inc. are thus fairly good. Not certain -- XYZ may not be able to support it at all -- but if it can be done in any practical way, odds are good that there will be software support that makes it look like the POSIX way. >This MUST be IN THE LANGUAGE STANDARD!!!!!! It MUST MUST MUST be there >(do you begin to feel the flame???) to FORCE vendors to, if necessary, >FIX THEIR OPERATING SYSTEMS SO IT WILL WORK... Language standards do not and cannot force vendors to do anything. Especially if the vendor is IBM -- one of the major problem areas with any character-at-a-time-read function -- which simply cannot be bullied by anything short of the US government. (It is not clear that even the US government can successfully bully IBM on an issue IBM cares about, but anybody less massive definitely can't.) Please get it through your head that standards committees have far less clout than you think. The question is not whether, say, IBM will be forced to spend millions complying; the question is whether IBM will accept the standard or ignore it. If you want to see a standard in wide use, you very badly want IBM to accept it. This may be ugly but it's the way the world works. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
fredex@cg-atla.UUCP (Fred Smith) (08/16/89)
In article <1677@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > > I agree that these should be part of the standard! Anyone who has >written a (more or less) portable program knows the joy of setting raw >mode one way for SysV, another for BSD, using raw read calls in CP/M and >MS-DOS, a calling sys$read_raw$some_long_name in VMS. It gets worse as >you go to TOPS, PRIMOS, etc. ------------------ Bill is right that the "diversity" of ways to do this is a real pain in the (very low) back. However, the particular method required on PRIMOS (one which he mentions) is rather trivial, especially when compared to the nightmarish rigamarole one goes thru on VMS to do anything! On Primos one only has to call T1IN which returns a single character from the user's login terminal. There is a complementary service which will tell you if there is a character waiting in your input buffer, but I don't happen to recall its name. Fred
john@frog.UUCP (John Woods) (08/16/89)
For the 1,807,235,997th time... In article <225800206@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > The language standards need some construct equivalent to what getch() > and kbhit() do on MSDOS. > This MUST be IN THE LANGUAGE STANDARD!!!!!! It MUST MUST MUST be there > (do you begin to feel the flame???) to FORCE vendors to, if necessary, > FIX THEIR OPERATING SYSTEMS SO IT WILL WORK Right. Call up International Business Machines, Incorporated, and tell them that they MUST MUST MUST change their extremely successful operating systems in order to make yourself happy. I'm sure we'll all be able to hear the laughter. -- John Woods, Charles River Data Systems, Framingham MA 508-626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/16/89)
In article <19095@mimsy.UUCP> chris@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.
seanf@sco.COM (Sean Fagan) (08/16/89)
In article <225800206@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >FIX THEIR OPERATING SYSTEMS SO IT WILL WORK This can be interpreted two ways (ambiguous, you know), and eitehr way is, imnsho, wrong. I have *yet* to *really* encounter a need to get a key as soon as it's pressed. If the ability is available, I might design things differently than if it weren't, but it's not something that will kill me if it's not there. The *only* place I've seen a need for something like that is in games, which, I regret to inform you, are not the staple of most programmers. Just because an OS does efficient I/O does not mean it is broken. Also, as someone else pointed out (Chris Torek?), it is not cost-efficient to do this for most OS's. IBM's virtual card punch is his example; I prefer NOS's virtual tape file, since Cyber's were much faster than IBM's in their day (and for quite a few days afterwards). Sometime when you can, take a look at sam running on a blit-type terminal. It doesn't require single-character I/O, yet, according to the people who use it, it's the greatest thing since sliced bread. FSE on the cyber's didn't require it, and it worked fine, despite what other people might say. Face it: how to do such a thing is an OS-specific feature. If you must know the truth, I question malloc's need to be in the standard. However, it is necessary to write portable, *useful* programs, so it should be in there. Doing scio is, however, *not* necessary for the same. Incidently, I didn't see you require a method of turning echoing off and on; why not? A request for that comes up about as often as "ReadKey()" does, and is about as portable and useful. As other people pointed out, if a standard requires a feature that cannot be implemented, than nobody will use the standard. -- Sean Eric Fagan | "Uhm, excuse me..." seanf@sco.UUCP | -- James T. Kirk (William Shatner), ST V: TFF (408) 458-1422 | Any opinions expressed are my own, not my employers'.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/16/89)
In article <1989Aug15.161101.19925@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >(I would expect OS/2 to provide POSIX compliance at some point, for example.) I've heard the latest release of VAX/VMS touted as POSIX-compliant, for another example.
peter@ficc.uu.net (Peter da Silva) (08/16/89)
The guy Henry's following up to did rant most egregiously, but... In article <1989Aug15.161101.19925@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > The point is, the POSIX way of > doing things is the closest there is to an OS-independent standard;... But it's not. In particular the Posix method of creating new processes is highly OS-dependent. It requires major hackery to get it to work anywhere but UNIX, and a large number of operating systems can't implement it at all. POSIX is not the answer to the gaps that (by necessity) exist in the ANSI C standard. If POSIX is UNIX under another name, to satisfy DoD competitive bidding requirements, fine. But don't start talking about it as an OS-independant standard when it isn't one. The closest thing there is to an OS-independant standard, at least for the services covered by it, is the Software Tools virtual operating system. It's inspired by UNIX and C, but doesn't require the UNIX model to work. Perhaps it would be a good starting point for a REAL OS-interface standard. > Language standards do not and cannot force vendors to do anything. Neither can OS standards. > Please get it through your head that standards committees have far less > clout than you think. POSIX included. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "The sentence I am now Personal: peter@sugar.hackercorp.com. `-_-' | writing is the sentence Quote: Have you hugged your wolf today? 'U` | you are now reading"
davidsen@sungod.crd.ge.com (ody) (08/16/89)
In article <19095@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: | What does `kbhit()' mean when stdin is a socket? How about in a VMS | batch job? kbhit() returns true if a single character blocking read would return data right now. This seems to be pretty well defined for batch, pipe, socket, etc. | | What does getch() do at end of file? A good point. As it's intended to be used, there is no end of file... the user can always type another character. I don't think anyone would object if the definition were extended to allow it to return EOF (it's already an int, so that is a legal thing to do). Currently the MSC version hangs on input waiting for more data. I don't see any great dificulties in implementing these with streams, etc, either. The object of kbhit() is to determine if a read will block or get data, and the object of getch is to read just one character, with no echo (assuming that echo is taking place at all). Both of these things can be done on most hosted systems, as evidenced by programs which do them. The MSC version included conio.h, and if an environment can't provide the service it doesn't provide the header. This whole issue is really "my brain-damaged o/s can't do a lot of things, don't put them in the standard." Rather than avoid defining a standard for these commonly needed functions, it seems better to adopt the principle of defining how they should be done, and leaving the vendor to admit deficiencies in the o/s if they can't. Long global names seem to fall in this category, too. At some point X3J11 should just add them to the standard, and let vendors run a long to short name conversion as part of the compilation process. It can be done. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
leea@ssc-vax.UUCP (Lee Carver) (08/16/89)
In article <19095@mimsy.UUCP> chris@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. Yes, but kbhit() can be "well defined" for all streams. kbhit() should return true if the next "getch()" (or read ( fd, buf, 1 )) will NOT block. This means that the data must already be available to the OS, and simply awaits transfer to the application.
dell@amelia.nas.nasa.gov (Thomas E. Dell) (08/17/89)
>I have *yet* to *really* encounter a need to get a key as soon as it's >pressed. If the ability is available, I might design things differently >than if it weren't, but it's not something that will kill me if it's not >there. The *only* place I've seen a need for something like that is in >games, which, I regret to inform you, are not the staple of most >programmers. How about.. - You want to have abort/flush/whatever characters in your application that are not handled by unix - You don't want your characters echoed back when you type them, but when they are used (as fill-in-the-blank applications, etc). Echo-as-you-type is often undesirable. - You want to add more line edit capabilities, such as ^W to erase a word, or whatnot. - You have prompts where no [return] is desired, as a yes/no, etc. I've never written a game in my life.. These are all problems quality applications program have coping with the many varieties of unix.. Many times the default behavior is damn ugly, unusable, or worse. dell@ames-nas.arpa .. or apple!spies!uuwest!lunatic
Kevin_P_McCarty@cup.portal.com (08/17/89)
In <19095@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: >What does `kbhit()' mean when stdin is a socket? How about in a VMS >batch job? kbhit() in the absence of a keyboard owned by the process behaves similarly to pod_bay_doors_open() in the absence of pod bay doors owned by the process, namely, the behavior is undefined. It is an error to interrogate a device which does not exist. kbhit() interrogates the status of a device. stdin is not a device. kbhit() is in the same class as left_mouse_button_pressed(). Neither has anything to do with C language; neither belongs in a language standard; they are idiosyncratic to hardware. >What does getch() do at end of file? Why, it returns EOF. getch() returns an int, same as getchar(). Kevin McCarty
Kevin_P_McCarty@cup.portal.com (08/17/89)
In <10746@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >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. Agreed, except that such an environment, with its canonicalized input, does not encompass every application. Such an environment is not the only one for which C programs are written. kbhit() and getch() are appropriate for low level control of a mechanical control device called a keyboard. The physical similarity of a keyboard in this environment to a keyboard used as a text entry device in the traditional environment is mostly coincidental. Programming with kbhit() and getch() is programming for an embedded system, where keyboard input is event oriented rather than text oriented, and is handled in the same fashion as mouse, joystick or pushbutton input, for example for cursor movement or one-key mode switching. Examples would be games and other visual simulations, using PCs as hardware controller or test instrument consoles, prototyping of things like ATM terminals, microwave ovens, VCRs or what have you. These are not really environments which you would call hosted, even though other services a hosted environment provides are present. This miscellaneous collection of applications lies in the single user, single tasking region somewhere between microcontrollers running embedded firmware and Real Computer Systems (tm) running a Real Operating System (tm). Somewhere closer to the former than the latter. This area was opened up by the personal computers from IBM and others, where the operating system is barely a command line with a file system on top of a BIOS. It is mostly programmers writing applications suited for these rudimentary platforms who need kbhit() and getch(). They only need them for embedded system types of programs, not for any applications which have a hope of porting elsewhere. kbhit() and getch() work suitably well wherever they appear, and they seem to appear wherever they are suitable. I see no need to go beyond the current state of affairs. Just because they are useful for some kinds of programming is no reason to canonize them into the language for everybody. (It should be noted that library functions are not guaranteed to be available in a non-hosted environment anyway.) Kevin McCarty
nather@ut-emx.UUCP (Ed Nather) (08/17/89)
In article <19095@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > In article <1677@crdgw1.crd.ge.com> davidsen@sungod.crd.ge.com (ody) writes: > >[...] Therefore, since > >kbhit() and getch() are probably the widest spread, I would suggest that > >the MS-DOS haters would still like to adopt this convention, since it > >would simplify porting programs to other operating systems. > > 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. Another question: if we adopt kbhit() do we debug it first, or continue the bugs into the next generation? As an example, kbhit() as implemented in MS-DOS has an undocumented "feature" I had to program around: when the character input on the keyboard is the Ctrl-C code, and kbhit() is invoked to see if a character is waiting, it takes it upon itself to abort the program under execution. I doubt we'd want to perpetuate such a lousy example of the desired function. -- Ed Nather Astronomy Dept, U of Texas @ Austin
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/17/89)
In article <21372@cup.portal.com> Kevin_P_McCarty@cup.portal.com writes: >Agreed, except that such an environment, with its canonicalized input, >does not encompass every application. Such an environment is not the >only one for which C programs are written. And neither is a direct keyboard reading one. Therefore it would be inappropriate for a universal standard to attempt to legislate either behavior. >Programming with kbhit() and getch() is programming for an embedded >system, ... While getchar() etc. are required only in a hosted environment. A hosted environment is supposed to provide a fairly cozy set of capabilities. Although input canonicalization is not specifically required, it is the sort of thing that might be reasonably expected in a hosted environment. >It is mostly programmers writing applications suited for these >rudimentary platforms who need kbhit() and getch(). They only need them >for embedded system types of programs, not for any applications which >have a hope of porting elsewhere. That is what the C Standard calls a "freestanding" environment. Since freestanding environments vary much more widely than hosted ones, the Standard attempts to constrain them as little as possible. For those that have keyboards, perhaps kbhit() and getch() would be useful things for the implementation to provide. It's not clear that a flight control system should be burdened with them. >I see no need to go beyond the current state of affairs. >Just because they are useful for some kinds of programming is >no reason to canonize them into the language for everybody. Right on!
henry@utzoo.uucp (Henry Spencer) (08/17/89)
In article <5711@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> The point is, the POSIX way of >> doing things is the closest there is to an OS-independent standard;... > >But it's not. In particular the Posix method of creating new processes is >highly OS-dependent... Sigh, Peter, you have *completely* missed my point. I wasn't saying that you could do POSIX on any operating system. Note the word "standard". My point is that POSIX, good or bad, is a *standard* operating system interface, with a formally-ratified manufacturer-independent document defining it and a great many standards organizations (and influential customers and suppliers) putting their weight firmly behind it. Even Unix's major competitors are swearing up and down that they will be POSIX compatible if it kills them (and it's certainly going to be painful for Microsoft, say, to reverse all its pathname slashes :-)). The odds of finding a POSIX-compatible interface on a random computer from XYZ Vaporboxes Inc. will be *far* higher than the odds for any other specific interface. Even people who cannot be fully compatible, say because they can't implement fork(), will try to be as compatible as possible, say in how you ask for raw keyboard input. >POSIX is not the answer to the gaps that (by necessity) exist in the ANSI >C standard. Perhaps not. But I don't see any superior alternative that is likely to gain the same volume of support, acceptance, and implementation. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bph@buengc.BU.EDU (Blair P. Houghton) (08/18/89)
In article <3180@scolex.sco.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > >The *only* place I've seen a need for something like that is in >games, which, I regret to inform you, are not the staple of most >programmers. No. The real biggie is editors. What I want to know is, how does EDT work, if VMS can't handle character-at-a-time devices. --Blair "And on block-mode terminals, how do you force a break?"
davidsen@sungod.crd.ge.com (ody) (08/19/89)
In article <21371@cup.portal.com> Kevin_P_McCarty@cup.portal.com writes: | >What does getch() do at end of file? | | Why, it returns EOF. getch() returns an int, same as getchar(). It hangs in every implementation I've tried... I agree it *should* return EOF, but it doesn't. Without EOF it can't be used on pipes/streams/sockets or whatever you like. bill davidsen (davidsen@crdos1.crd.GE.COM) {uunet | philabs}!crdgw1!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
scs@adam.pika.mit.edu (Steve Summit) (08/20/89)
In article <17228@ut-emx.UUCP> nather@ut-emx.UUCP (Ed Nather) writes: >...kbhit() as implemented in MS-DOS has an undocumented "feature" >I had to program around: when the character input on the keyboard is the >Ctrl-C code, and kbhit() is invoked to see if a character is waiting, it >takes it upon itself to abort the program under execution. Actually, I often use this as a feature: since control-C under DOS isn't really an interrupt, but rather checked for under a finite set of circumstances, I often put (void)kbhit(); in the middle of a loop that it's important to be able to abort. (For those of you who haven't had the delicious pleasure of programming this divine marvel of archaic computer technology, the simple program main() { while(1); } locks a PC up until you reboot it.) I don't know why control-C's are polled under DOS; the low-level keyboard scan codes do come in as true interrupts, so a proper, asynchronous control-C interrupt could have been generated. Actually, I'm not sure a control-C during a kbhit() will abort the program if a control-C during any other input operation wouldn't have either. You're supposed to able (under Microsoft C, anyway) to use signal(SIGINT, ...) to catch or ignore control-C's. (I could be wrong; I've got a program that is choking on control-C's but shouldn't be, and it uses kbhit.) I think there are actually two pairs of kbhit- and getch-like interrupts, one at the DOS level and one at the BIOS level. As I recall, they differ as to whether or not they're redirectable along with stdin, and whether or not they treat control-C as an "interrupt" or just another character. (Surprisingly, whether or not things like control C checking and input line editing -- the character-at-a-time issue that started this thread -- happen can depend on what call you use to ask for characters, not on global modes as they do under Unix.) It's possible to pick the wrong set of functions, with amusing and/or disastrous results. A friend accidentally typed format which reformats the current disk; in her case the hard disk. Fortunately, she tried this under a later DOS version, which asked for confirmation (I've heard that the earlies DOS versions didn't even do that). Unfortunately, the confirmation prompt was (rather) ill-conceived -- it said something like: formatting disk C: -- press any key to continue Not wanting to format drive C:, she hit control-C -- which was taken to be "any key," and the formatting continued... (a colleague informed her, too late, that the correct response at that point was to turn the machine off). Steve Summit scs@adam.pika.mit.edu
scs@adam.pika.mit.edu (Steve Summit) (08/20/89)
In article <3802@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >What I want to know is, how does EDT work, if VMS can't handle >character-at-a-time devices. Someone was mistaken when they implied that VMS cannot do character-at-a-time input. In fact, I know of at least three ways to do it (for terminals): 1. with a SETMODE $QIO, analogous to CRMOD (there's also one like RAW) 2. with a per-function modifier on an individual READ $QIO 3. by doing the $QIO equivalent of read(fd, &c, 1) Number 3 was a surprise. It might be a bug; I don't know if it's documented. It came up when a colleague (Hi, Phil!) ported ed to VMS using a Unix I/O emulation package I had written -- he complained that for some reason he couldn't do input line editing while in ed. It turns out that ed does reads of 1 from standard input. I believe this dates to a very old version of Unix when it was important to do so to avoid reading past a !, the characters following which had to be left in some input buffer for the shell to read during a shell escape. This is no longer appropriate for comp.lang.c, but belongs in comp.unix.ancient.history... Steve Summit scs@adam.pika.mit.edu
chris@mimsy.UUCP (Chris Torek) (08/21/89)
>In <19095@mimsy.UUCP> I asked: >>What does `kbhit()' mean when stdin is a socket? How about in a VMS >>batch job? In article <21371@cup.portal.com> Kevin_P_McCarty@cup.portal.com writes: >kbhit() in the absence of a keyboard owned by the process behaves >similarly to pod_bay_doors_open() in the absence of pod bay doors owned >by the process, namely, the behavior is undefined. It is an error to >interrogate a device which does not exist. This is a reasonable definition (although not the one I would choose for those times I have wanted something like this). >>What does getch() do at end of file? >Why, it returns EOF. getch() returns an int, same as getchar(). Again, a reasonable definition---but as others point out, not what MSDOS does. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
seanf@sco.COM (Sean Fagan) (08/21/89)
In article <3802@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >In article <3180@scolex.sco.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >>The *only* place I've seen a need for something like that is in >>games, which, I regret to inform you, are not the staple of most >>programmers. As I've pointed out before, I worked for about two years on a system that didn't have single-character I/O, yet had a very nice full-screen editor (specifically, FSE under NOS running on a CDC Cyber 170/760). Doug Gwynn uses, I believe, an editor which doesn't use scio either (sam running on a DMD 630). Maybe I should have been a bit clearer: I have not really seen a need for a portable way to do this, except for games and the like. Most other programs will *not* be portable to all systems supporting C (MicroEmacs, and editor which is fairly portable, does it by being #ifdef'd and relying on unix compatable libraries), so having a "portable" scio routine such as ReadKey() is not really helping things. Both proponents and conponents (is that a real word? it should be...) will be able to drag up examples to support their cause. For my side, I'd only suggest programming for a while on a Cyber (or, if you can't do that, on an IBM system with virtual card-punches); you will, eventually, learn that scio is *not* necessary for most things, and the lack is only a bit inconvenient at time. -- Sean Eric Fagan | "[Space] is not for the timid." seanf@sco.UUCP | -- Q (John deLancie), "Star Trek: TNG" (408) 458-1422 | Any opinions expressed are my own, not my employers'.
les@chinet.chi.il.us (Leslie Mikesell) (08/21/89)
In article <2855@ssc-vax.UUCP> leea@ssc-vax.UUCP (Lee Carver) writes: >>What does `kbhit()' mean when stdin is a socket? How about in a VMS >>batch job? >>Before you settle on <X> as a standard across hundreds of systems, be sure >><X> can well-defined everywhere. >Yes, but kbhit() can be "well defined" for all streams. kbhit() >should return true if the next "getch()" (or read ( fd, buf, 1 )) >will NOT block. This means that the data must already be available >to the OS, and simply awaits transfer to the application. But what we really need is a way to determine *how many* characters can be requested by a read() on an arbitrary stream (tty/file/pipe) without blocking. If you are going to ask for some new standard it might as well be useful - moving data with 1 character read()'s is not a good way to do things. Les Mikesell
peter@ficc.uu.net (Peter da Silva) (08/21/89)
Warning... malicious MS-DOS reminiscence ahead. In article <13653@bloom-beacon.MIT.EDU>, scs@adam.pika.mit.edu (Steve Summit) writes: > format > formatting disk C: -- press any key to continue I got bit by that too, but in my case it was on an early version of DOS, which provided the wonderfully malicious message: Insert a floppy in drive C: and hit RETURN. Ah yes... -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "Optimization is not some mystical state of grace, it is an intricate act U of human labor which carries real costs and real risks." -- Tom Neff
peter@ficc.uu.net (Peter da Silva) (08/21/89)
In article <13656@bloom-beacon.MIT.EDU>, scs@adam.pika.mit.edu (Steve Summit) writes: > It turns out that ed does reads of 1 from standard > input. I believe this dates to a very old version of Unix when > it was important to do so to avoid reading past a !, the > characters following which had to be left in some input buffer > for the shell to read during a shell escape. Ah yes. If anyone ever wondered about the point of the '-t' option of sh, that's what it was for... -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "Optimization is not some mystical state of grace, it is an intricate act U of human labor which carries real costs and real risks." -- Tom Neff
scott@bbxeng.UUCP (Engineering) (08/21/89)
In article <13653@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >Actually, I often use this as a feature: since control-C under >DOS isn't really an interrupt, but rather checked for under a >finite set of circumstances, I often put > > (void)kbhit(); > >in the middle of a loop that it's important to be able to abort. [ stuff deleted ] >I don't know why control-C's are polled under DOS; the low-level >keyboard scan codes do come in as true interrupts, so a proper, >asynchronous control-C interrupt could have been generated. > >Actually, I'm not sure a control-C during a kbhit() will abort >the program if a control-C during any other input operation >wouldn't have either. You're supposed to able (under Microsoft >C, anyway) to use signal(SIGINT, ...) to catch or ignore >control-C's. [more stuff deleted] There is only *one* true break interrupt in a PC - CONTROL+BREAK. The bios checks for this key combination and does a special INT call. All you have to do is hook in to the appropriate interrupt vector location and you may trap CTRL+BREAK till the cows come home. The ^C interrupt is implemented as a DOS *feature*. DOS will check for it only at certain times so it is possible that it won't always be acknowledged. Also, my experiences are that DOS will only recognize ^C if it is at the front of the input buffer. Try this: Start up a long output (TYPE a large ascii file). Hit ^C (The output aborts) Start up the long output again Hit some other character first Now hit ^C (The output does NOT stop - CTRL+BREAK will stop it) When output finishes - you will then see the ^C. It is true that you can trap ^C interrupts but even if you trap the ^C DOS will still print a "^C" on the screen. I fail to see why Microsoft considers this acceptable. I don't need little ^C's all over my display. Your best bet is to leave ^C out of the picture entirely. In Turbo C (tm) there are simple function calls (whose names I don't have in front of me) that check the keyboard status and read the keyboard without any ^C problems (in fact, ^C is read just like any other character). I believe these functions are a call to DOS's direct-console-io function (which also does not echo the input - very handy). -- --------------------------------------- Scott Amspoker Basis International, Albuquerque, NM 505-345-5232
john@frog.UUCP (John Woods) (08/22/89)
In article <2855@ssc-vax.UUCP>, leea@ssc-vax.UUCP (Lee Carver) writes: > ...kbhit() can be "well defined" for all streams. kbhit() > should return true if the next "getch()" (or read ( fd, buf, 1 )) > will NOT block. This means that the data must already be available > to the OS, and simply awaits transfer to the application. Block for how long? Does this mean that a disk file will return false if the block isn't already in the in-memory disk cache? If it must return true, what if some clucko has accidently powered off that disk drive? [I once did this accidently to an HP3000. It patiently waited for me to notice my mistake and turn it back on, gently chiding me on the console. Nary a hiccup other than that.] How about a device driver that presents data to the kernel, but invalidates it if not read in time? Gee, maybe it isn't so well defined... -- John Woods, Charles River Data Systems, Framingham MA 508-626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
richard@calvin.EE.CORNELL.EDU (Richard Brittain) (08/22/89)
In article <13653@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >I don't know why control-C's are polled under DOS; the low-level >keyboard scan codes do come in as true interrupts, so a proper, >asynchronous control-C interrupt could have been generated. > Actually, control-break generates a very low-level asynchronous interrupt which will get out of most problems, but the default handler for this interrupt just empties the keyboard buffer and sticks a ^C in there, because it doesn't know if it is "safe" to terminate the program. I suspect if you installed your own control-break handler you could break out of many of these wonderful little 1-liners that lock up our pc's , but it probably would introduce it's own problems. My own 2 cents on the question of standardising single character unbuffered i/o: It seems to me that what is needed is not only a reliable way to perform single character keyboard reads, but also an easy way to detect function key use. I know that you can do this if you have curses/terminfo AND you are prepared to meet miscellaneous operating system gremlims face to face. Unix has a reputation for being user hostile, and isn't this perhaps because writing a nice user interface without standardised, portable routines is such a pain that hardly anyone bothers to even attempt it. Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.spp.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard
tainter@cbnewsd.ATT.COM (johnathan.tainter) (08/24/89)
In article <13653@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >I don't know why control-C's are polled under DOS; the low-level >keyboard scan codes do come in as true interrupts, so a proper, >asynchronous control-C interrupt could have been generated. The reasoning I have seen is that the BIOS is so fragile it cannot stand to have interrupts that do nontrivial things (like the DOS equivalent of tearing down a process) so they have to insure that ^C is only checked in known states of the BIOS. Thus this abomination before G*d of having it checked on i/o operations only. This might be of interrest. Of what I have seen of UNIX implementations they avoid this problem by mapping the 'hardware' interrupt into a 'software' interrupt (a signal) and checking for software interrupts when the process gets restarted after a suspend (i.e. in a known state). --johnathan.a.tainter-- att!ihlpb!tainter
ok@.cs.mu.oz (Richard O'Keefe) (08/30/89)
In article <3802@buengc.BU.EDU>, bph@buengc.BU.EDU (Blair P. Houghton) writes: > No. The real biggie is editors. > What I want to know is, how does EDT work, if VMS can't handle > character-at-a-time devices. When SYS$GET() reads a record from a terminal, the record may be terminated by CRLF **or by an escape sequence** (there are a couple of other cases). EDT is driven by the keypad, and those keys send escape sequences. Think of it as every record being <text> <edit command>.
scs@hstbme.mit.edu (Steve Summit) (08/31/89)
In article <1979@munnari.oz.au> ok@.cs.mu.oz (Richard O'Keefe) writes: >In article <3802@buengc.BU.EDU>, bph@buengc.BU.EDU (Blair P. Houghton) writes: >> What I want to know is, how does EDT work, if VMS can't handle >> character-at-a-time devices. >EDT is driven by the keypad, and those keys send escape sequences. >Think of it as every record being <text> <edit command>. This is correct, but EDT is in fact truly character-at-a-time. It is modeless, and each printing character appears, inserted, as soon as it is typed. In a previous article I outlined several ways to do true single- character reads from terminals under VMS. It's straightforward; no harder than under Unix.
mcdonald@uxe.cso.uiuc.edu (08/31/89)
In article <3802@buengc.BU.EDU>, bph@buengc.BU.EDU (Blair P. Houghton) writes: > No. The real biggie is editors. > What I want to know is, how does EDT work, if VMS can't handle > character-at-a-time devices. VMS can do input and output any way one wishes. It is just that by default everything goes through the "record manager". Single character, disk block or group of blocks (independent of the record structure), even absolute disk blocks, are all possible. They are just a programming nuisance, and some (absolute disk blocks e.g.) require priviledge. Even arcade games a possible on a (lightly loaded) VAX. Doug McDonald