tony@xenlink.UUCP (Tony Field) (12/30/88)
(I am posting this on comp.lang.c and comp.unix.wizards. If this is inappropriate for either group, my mistake.) I wonder why C i/o functions - including curses - do not provide a simple method of accepting 'fixed format' screen input? The following example illustrates the problem and also shows a simple solution. Often, a programmer must construct complex data acquisition screens that have a number of user-enterable fields. For example, a Human Resources system might need a screen that looks like: +-----------------------------------------------------------------------------+ | H U M A N R E S O U R C E S | | | | NAME: ______________________________________ DEPARTMENT: _ __ | |ADDRESS: __________________________________________ | | __________________________________________ | | __________________________________________ | | | | S.I.N.: ___ ___ ___ PHONE: ___ _______ (RES) | | | |MONTHLY BASE SALARY: __________ YEARLY BASE SALARY: __________ | +-----------------------------------------------------------------------------+ The normal way of solving this problem is to develop special code to allow the user to traverse the screen. What the programmer really wants to do is say, "Here is a screen image. Place the user's data field responses into these variables.". I have seen many "data windows" packages - mostly in MSDOS - but none of them seems to follow the spirit of C. In spirit, all formatted display in C should follow the general conventions of "printf/sscanf". For example, the Human Resources screen could be presented to the user with the following type of code: wstart (editsub,BLUE,GREEN,GREY,BLUE,BAR); wdefine (20,0," H U M A N R E S O U R C E S "); wdefine (0,4," NAME: %40s DEPARTMENT: %1c %3d",hr.name,&hr.dept,&hr.dnumb); wdefine (0,5,"ADDRESS: %40s",hr.addr1); wdefine (9,6,"%40s",hr.addr2); wdefine (9,7,"%40s",hr.addr3); wdefine (9,9,"S.I.N.: %-10ld PHONE: %20s (res)",&hr.sin,hr.phone); wdefine (0,11,"MONTHY BASE SALARY $%10.2lf",&hr.salary); wdefine (40,11,"YEARLY BASE SALARY $%10.2plf",&yearly); do { wfetch_screen (); error_code = edit_user_data (&hr); } while (error_code); The function "wstart" prepares the software to accept a new screen definition. In addition it provides colour (or other) attributes for prompt and data fields. The "wdefine" function calls set up the various data fields and places the various prompts and current contents of the data fields on the screen. The parameters first specify the x-y screen coordinates, the formatting string for the prompts and data fields, and the the ADDRESS of the various data items (like sscanf). Simple analysis of the format string can easily segregate the "prompt" information from the formatting description of the data items. In addition, sufficient information is provided to locate the x-y coordinate, size, and type of every data field. After the screen has been defined with "wdefine", a single call to function "wfetch_screen" can walk the user through the entire screen structure (even in a user-defined random pattern). When wfetch_screen returns, the programmer can assume all of the variables have been filled in by the user. The programmer's error checking routine can be called until the user's data is error-free. The mechanism presented above illustrates a screen presentation style that is familiar to IBM-3270 programmers (and dBase programmers) : i.e. present a screen to the user, fetch all his responses, then edit the data. Simple extensions could be made to allow field-by-field data editing. This would be more consistent with programming styles on *nix system. The field-by-field editing also can allow 'dynamic data help' to provide user with help information. I feel that C really needs a cleaner method of accepting screen input than currently provided by printf/curses. There should be a 'standard C library' set of functions, consistent with the style of C, that allow full-screen data presentation. If any one is interested in this general problem, I would appreciate their comments. In addition, I could provide a bunch of C code (that currently runs under Xenix or QNX) that implements all of the above.
les@chinet.chi.il.us (Leslie Mikesell) (12/30/88)
In article <19@xenlink.UUCP> tony@xenlink.UUCP (Tony Field) writes: >I wonder why C i/o functions - including curses - do not provide a simple >method of accepting 'fixed format' screen input? The following example >illustrates the problem and also shows a simple solution. [....] >If any one is interested in this general problem, I would appreciate >their comments. In addition, I could provide a bunch of C code (that >currently runs under Xenix or QNX) that implements all of the above. I would like to see something like this but extended so that if the terminal is actually a PC running a special terminal emulation program the editing would be handled locally. The host would just pass the input form and field parameters and tell the terminal whether it wanted the the response back by charcter, field or full screen. I would want to do this over a network with a unix host, PC's as terminals, with the users unaware that the application was not running under DOS, but is seems like something that would be generally useful regardless of the physical link. Given the popularity of PC's as terminals, I'm surprised this hasn't been done (or has it?). Les Mikesell
is813cs@pyr.gatech.EDU (Cris Simpson) (12/30/88)
In article <19@xenlink.UUCP> tony@xenlink.UUCP (Tony Field) writes: >I wonder why C i/o functions - including curses - do not provide a simple >method of accepting 'fixed format' screen input? The following example >The normal way of solving this problem is to develop special code to >allow the user to traverse the screen. >What the programmer really wants to do is say, "Here is a screen image. >Place the user's data field responses into these variables.". I have seen >many "data windows" packages - mostly in MSDOS - but none of them seems >to follow the spirit of C. In spirit, all formatted display in C should >follow the general conventions of "printf/sscanf". >The mechanism presented above illustrates a screen presentation style >that is familiar to IBM-3270 programmers (and dBase programmers) : i.e. >present a screen to the user, fetch all his responses, then edit the >data. > >I feel that C really needs a cleaner method of accepting screen input >than currently provided by printf/curses. There should be a 'standard >C library' set of functions, consistent with the style of C, that >allow full-screen data presentation. > >If any one is interested in this general problem, I would appreciate >their comments. In addition, I could provide a bunch of C code (that >currently runs under Xenix or QNX) that implements all of the above. To me, the best thing about C is that it is no bigger than it has be. To say that there should be a 'standard C library' of screen data functions conflicts with the philosophy, style and practice of C. If you need this, there are probably better ways to get it than to ask for it to be included in the stdlib. I have no use for it, but say that I wanted sound functions. Should they be in the stdlib? Naah. I could write some sound functions if my box had sound, or I could buy a package that supported it. But it is of limited utility to the general world and definitely non-portable. If this is something that dBase does so well, why not use that. Or try a dBase compiler. The right tools make any job easier. If you need to drive a nail, don't hit it with a crescent wrench, it messes up the wrench and doesn't do that good a job, either. cris
stuart@bms-at.UUCP (Stuart Gathman) (01/03/89)
The static screen presentation wheel has been invented many times over.
There are numerous packages available for purchase or free, many including
source code. A useful discussion for the net might be what features
could/should be standardized.
The great thing about 'C', is that you can always roll your own. We
did just that - it is not that big a project and includes pop up windows
and the works. AT&T curses is so buggy, we had no choice but to
replace it. The worst curses performance problem is that every character
requires a function call(s). A low level display string function does
wonders. Our screen programs went from 100K with AT&T curses to
30K with BMS curses. (NOTE, any PD curses is better than AT&T.)
We use a "screen painter" to define data entry windows. Dynamic windows
similar to the original posters are also used for things like multiple
choice lists. Both approaches have advantages.
We have a verify function for each field defined in a table. This allows
the same application to work in either a full duplex or block
environment. Only the field tab library module changes to accomodate.
In full duplex mode, the verify function is called immediately on field
exit. In block mode, all are called on "ENTER". This could be
a run time choice with terminfo/cap extensions to support block mode.
My list of necessary features would include:
1) both full duplex and block mode support.
2) user definable formatting and verification.
3) both painted and dynamic windows.
4) independent windows
5) table driven terminal configuration (terminfo,termcap)
6) dynamic attribute control with good defaults
7) both WP and DATA style fields
13) IBM mode to disable type ahead :-)
A good book on the window level is "Ascii display programming in C".
--
Stuart D. Gathman <stuart@bms-at.uucp>
<..!{vrdxhq|daitc}!bms-at!stuart>jcbst3@cisunx.UUCP (James C. Benz) (01/04/89)
In article <19@xenlink.UUCP> tony@xenlink.UUCP (Tony Field) writes: > > >(I am posting this on comp.lang.c and comp.unix.wizards. If this is >inappropriate for either group, my mistake.) > >I wonder why C i/o functions - including curses - do not provide a simple >method of accepting 'fixed format' screen input? The following example >illustrates the problem and also shows a simple solution. The Perform program released by Informix with the original non-SQL non-4GL version 3.30 does just that - you feed it a text file with the screen image you want, and it sets up a data-entry screen for the user. Although it is specifically for use with Informix type data files, the concept is one that I would also like to see in a standard library, because this package routine often allows the user access to functions that I would prefer to restrict (like remove of data records) and to functions that are either confusing or superfluous to the desired application. (like Current, or the Screen command on one-screen forms).
gpasq@picuxa.UUCP (Greg Pasquariello X1190) (01/04/89)
In article <19@xenlink.UUCP> tony@xenlink.UUCP (Tony Field) writes:
-
-
-I wonder why C i/o functions - including curses - do not provide a simple
-method of accepting 'fixed format' screen input? The following example
-illustrates the problem and also shows a simple solution.
-
Because this is the function (no bad pun intended) of a library. You can
chose whatever library that you want that does the job. If the library is
good enough, or fills a particular niche, it may become "de-facto" standard.
Remember that C provides no I/O. This needs to be provided by the (operating)
system.
Greg Pasquariello
--
=============================================================================
Dirt is the mother o' lunch Greg Pasquariello AT&T/EDS
att!picuxa!gpasq
=============================================================================vch@attibr.UUCP (Vincent C. Hatem) (01/04/89)
In article <144@bms-at.UUCP>, stuart@bms-at.UUCP (Stuart Gathman) writes: } : } : } : } and the works. AT&T curses is so buggy, we had no choice but to } replace it. The worst curses performance problem is that every character } requires a function call(s). A low level display string function does } wonders. Our screen programs went from 100K with AT&T curses to } 30K with BMS curses. (NOTE, any PD curses is better than AT&T.) Come, come now... AT&T didn't invent it - they stole it from Berkley. Another wonderful product from Berkley. ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} ;-} -Vince
cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) (01/04/89)
In article <79@attibr.UUCP>, vch@attibr.UUCP (Vincent C. Hatem) writes: > In article <144@bms-at.UUCP>, stuart@bms-at.UUCP (Stuart Gathman) writes: > } : > } and the works. AT&T curses is so buggy, we had no choice but to > } replace it. The worst curses performance problem is that every character > } requires a function call(s). A low level display string function does > } wonders. Our screen programs went from 100K with AT&T curses to > } 30K with BMS curses. (NOTE, any PD curses is better than AT&T.) > > Come, come now... AT&T didn't invent it - they stole it from Berkley. Partially true. While curses was a Berkeley invention, it has been radically modified at AT&T, including the development of terminfo, the addition various sub-window routines, support for color, and amazing speed increases. The question is, are you comparing an outdated AT&T version of curses (say sVr2) to a new release of curses from another company. Why not try getting a hold of the sVr3.2 curses? I'm not trying to be pro-AT&T (I don't even work for them, I'm a contractor), I just think their _current_ product is good, and that you're possibly not referring to it. Besides, who uses a character terminal any more :-) :-) :-) :-) -- Christopher J. Calabrese AT&T Bell Laboratories att!ulysses!cjc cjc@ulysses.att.com
knudsen@ihlpl.ATT.COM (Knudsen) (01/05/89)
Speaking of libraries and interactive screen programs, it strikes me as criminal negligence that hardly any C standard libs include the inkey() function, which means "check whether a char has been typed on the keyboard; if so, return it; else return \0 (or whatever). DO NOT BLOCK." Even a blocking version (that would return a char once typed, without waiting for a newline) would be useful. Most OSes make the inkey() function possible, but hardly easy. I figured out how to do it in OS9, and someday I may borrow a chapter 7 of the sys-adm's U**X manual long enuf to write one for System V. I know it takes a lot of ioctl() bashing. I have also done the blocking version in U**X, using fcntl(). My point is that some guru should have figured out how to do inkey() on the OS in question and put this in the library. Then ordinary programmers wouldn't have to figure it out for the zillionth time. [Given that U**X was born on DEC machines with full-duplex TTYs, I'm surprised that the C library didn't get inkey() early on. I guess VI and EMACS didn't come till much later.] Anyway, it's the need for such functions that often keeps interactive applications from using the buffered (f-names) I/O fcns. Ironically, inkey() is built into every "toy" computer with BASIC in ROM. The joys of having no OS... -- Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen "Lawyers are like nuclear bombs and PClones. Nobody likes them, but the other guy's got one, so I better get one too."
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/05/89)
In article <11064@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes: >Besides, who uses a character terminal any more :-) :-) :-) :-) Exactly. That's why I don't support standardization of curses-like interfaces. It's an idea whose time has gone.
peter@ficc.uu.net (Peter da Silva) (01/05/89)
In article <79@attibr.UUCP>, vch@attibr.UUCP (Vincent C. Hatem) writes: > In article <144@bms-at.UUCP>, stuart@bms-at.UUCP (Stuart Gathman) writes: > } and the works. AT&T curses is so buggy, we had no choice but to > } replace it... > Come, come now... AT&T didn't invent it - they stole it from Berkley. The AT&T implementation and the Berkeley implementation have to be quite different internally. The BSD version uses the TERMCAP database, and the AT&T version uses the TERMINFO database. These databases are similar in goals, but quite different in design and implementation. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
wen@husc4.HARVARD.EDU (A. Wen) (01/05/89)
In article <8332@ihlpl.ATT.COM> knudsen@ihlpl.ATT.COM (Knudsen) writes: >Most OSes make the inkey() function possible, but hardly easy. >I know it takes a lot of ioctl() bashing. ... >My point is that some guru should have figured out how to do >inkey() on the OS in question and put this in the library. >Then ordinary programmers wouldn't have to figure it out >for the zillionth time. But it's very, very easy: (with cbreak mode set) #include <ioctl.h> char inkey() { int count=0; ioctl(0,FIONREAD,&count); return(count?getchar():NULL); } A. Wen wen@husc4.HARVARD.EDU wen@husc4.BITNET {seismo!harvard!husc4}
friedl@vsi.COM (Stephen J. Friedl) (01/05/89)
In article <11064@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes: >Besides, who uses a character terminal any more :-) :-) :-) :-) In article <9281@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > Exactly. That's why I don't support standardization of curses-like > interfaces. It's an idea whose time has gone. Doug, you are living in a dream world, one full of idealistic fantasy. You may like your Blit, but for every one of you, there are at least 50,000 people with Wyse 50s at their desks. For the majority of these people, a bitmapped interface would be massive overkill. No :-) Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for me only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backb
daveh@marob.MASA.COM (Dave Hammond) (01/05/89)
In article <9281@smoke.BRL.MIL> Doug Gwyn writes (re curses-based interfaces): > It's an idea whose time has gone. Are you saying that a (relatively) high-priced, ethernet-connected graphical display should be installed for every office manager, production assistant or data-entry operatory who performs simple data management tasks? Or perhaps that applications which don't require bitmap displays and mice would not benefit from a standardized set of menu, window and form management tools? I realize this is not a popular concept, but there is a large segment of the Unix population which is *not* involved with cutting-edge design and engineering tasks, but merely doing their mundane, daily work on a Unix machine. [ perhaps we should reissue teletypes for such trailing-edge tasks :-) ] -- Dave Hammond ...!uunet!masa.com!{marob,dsix2}!daveh
daveh@marob.MASA.COM (Dave Hammond) (01/05/89)
In article <8332@ihlpl.ATT.COM> knudsen@ihlpl.ATT.COM (Knudsen) writes: >Speaking of libraries and interactive screen programs, >it strikes me as criminal negligence that hardly any C standard >libs include the inkey() function, which means "check whether >a char has been typed on the keyboard; if so, return it; >else return \0 (or whatever). DO NOT BLOCK." If I understand your need, the fcntl VMIN and VTIM parameters may help. If you set VMIN=0 and VTIM>0, read() returns immediately if characters are available, or in VTIM 10th-secs if the queue is dry. I use VMIN=0,VTIM=1 to grab the next char, or return immediately if none is available. >Even a blocking version (that would return a char once typed, >without waiting for a newline) would be useful. Try reading with VMIN=1,VTIM=0. This is akin to the Berkeley CBREAK mode. -- Dave Hammond ...!uunet!masa.com!{marob,dsix2}!daveh
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/06/89)
In article <443@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
-In article <9281@smoke.BRL.MIL> Doug Gwyn writes (re curses-based interfaces):
-> It's an idea whose time has gone.
-Are you saying that a (relatively) high-priced, ethernet-connected
-graphical display should be installed for every office manager, production
-assistant or data-entry operatory who performs simple data management
-tasks? Or perhaps that applications which don't require bitmap displays
-and mice would not benefit from a standardized set of menu, window and form
-management tools?
-I realize this is not a popular concept, but there is a large segment of
-the Unix population which is *not* involved with cutting-edge design and
-engineering tasks, but merely doing their mundane, daily work on a Unix
-machine.
-[ perhaps we should reissue teletypes for such trailing-edge tasks :-) ]
Fine, if you make it a Teletype model 630. If an employee isn't worth
investing $2K for dramatically improved productivity then I feel sorry
for the employer.
Even mickey-mouse IBM PCs can support much better working environments
than traditional CRT forms.cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) (01/06/89)
In article <443@marob.MASA.COM>, daveh@marob.MASA.COM (Dave Hammond) writes: > In article <9281@smoke.BRL.MIL> Doug Gwyn writes (re curses-based interfaces): > > > It's an idea whose time has gone. > > Are you saying that a (relatively) high-priced, ethernet-connected > graphical display should be installed for every office manager, production > assistant or data-entry operatory who performs simple data management > tasks? Or perhaps that applications which don't require bitmap displays > and mice would not benefit from a standardized set of menu, window and form > management tools? First off, these machines are now available for under $2000. Examples are Acer's Xerbra, a terminal with an ethernet connector and an X server in rom, and Atari ST's running NeWS with some help from a BSD box. A few years ago, before the school I was going to ever dreamed of multi window terminals and workstations, everyone has at least two terminals on their desk (yes, I can switch between two keyboards - one in my lap and one on the desk - just as fast as between windows). Given that decent terminals cost at least $500, this isn't so much of a difference for the added flexibility that windows give you. > I realize this is not a popular concept, but there is a large segment of > the Unix population which is *not* involved with cutting-edge design and > engineering tasks, but merely doing their mundane, daily work on a Unix > machine. And there are lots of old terminals sitting around just waiting to be used (around here there are even a few bitmap machined collecting dust), but the price of bitmapped workstations keep falling fast enough to make it unreasonable to assume the necessity of additional support for dumb terminals in standard libraries. I'm not saying there's no need for such abilities, Bell Labs has devoted quite a bit of effort in this area in the past, but there are packages available to do these things already. I seem to remember a curses based widget library posted to the net a couple of months ago. -- Christopher J. Calabrese AT&T Bell Laboratories att!ulysses!cjc cjc@ulysses.att.com
bruce@blue.gwd.tek.com (Bruce Robertson) (01/07/89)
> Fine, if you make it a Teletype model 630. If an employee isn't worth > investing $2K for dramatically improved productivity then I feel sorry > for the employer. Please explain how a $2K model 630 is so much better than a $350 Wyse-50 for someone doing, say, database entry all day. Another example: factory floor diagnostics, which can benefit from screen manipulation, but don't really gain anything from graphics. -- Bruce Robertson bruce@blue.gwd.tek.com
guy@auspex.UUCP (Guy Harris) (01/07/89)
>If I understand your need, the fcntl VMIN and VTIM parameters "ioctl(TCSETA)" and company, not "fcntl". >may help. If you set VMIN=0 and VTIM>0, read() returns immediately >if characters are available, or in VTIM 10th-secs if the queue is dry. This works on UNIXes that have VMIN and VTIME (S3, S5, SunOS 4.0, some others). It doesn't work on older UNIXes, or non-UNIX systems; I think he wanted a routine that would, on all (or, at least, most) systems, do what was appropriate on that system (whether UNIX or not). >I use VMIN=0,VTIM=1 to grab the next char, or return immediately if >none is available. Try VTIME=0 instead (although this may not work under S3); that will return immediately, rather than after 1/10 second (which VTIME=1 does). >>Even a blocking version (that would return a char once typed, >>without waiting for a newline) would be useful. > >Try reading with VMIN=1,VTIM=0. This is akin to the Berkeley CBREAK mode. Actually, the equivalent of turning on V7 CBREAK (not Berkeley - they didn't invent CBREAK, AT&T did) is turning ICANON off and setting VMIN to 1 and VTIME to 0. VMIN and VTIME are meaningful only if ICANON is off.
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (01/07/89)
In article <992@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >In article <11064@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes: >>Besides, who uses a character terminal any more :-) :-) :-) :-) > >In article <9281@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: >> Exactly. That's why I don't support standardization of curses-like >> interfaces. It's an idea whose time has gone. > >Doug, you are living in a dream world, one full of idealistic fantasy. >You may like your Blit, but for every one of you, there are at least >50,000 people with Wyse 50s at their desks. For the majority of these >people, a bitmapped interface would be massive overkill. No joke. We have about 50 ASCII terminals and one 4014/VT 220 clone. The 4014-clone is great fun but no one wants to use it. Graphis at 19.2KB are SLOW. Our primary usage for UNIX is data entry. That's it. Our user's don't care if they are running UNIX or VMS or whatever. Most of them don't even know what an operating system is. Some of them think UNIX is worse than MS-DOS because it doesn't run Lotus 1-2-3. Sorry, but there are MANY dumb-old ASCII tubes out there. My Wyse-50 is not the only one. Sure, I'd love to drag the Visual 603 into my office and use it, except I like my Wyse-50 just fine. I don't do windows ;-) -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Now with 12 percent less fat than InterNet: jfh@rpp386.Dallas.TX.US | last years model ..." UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
peter@ficc.uu.net (Peter da Silva) (01/07/89)
In article <9281@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <11064@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes: > >Besides, who uses a character terminal any more :-) :-) :-) :-) > > Exactly. That's why I don't support standardization of curses-like > interfaces. It's an idea whose time has gone. When there's a recognised standard for bitmapped displays, then you can say the need for curses is gone. In the meantime, curses is the best tool we have... it's the only one that lets you do the job (presenting 2-d textual data in a machine-independent way). STDWIN is a nice start at a replacement, but it's pretty complex. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
peter@ficc.uu.net (Peter da Silva) (01/07/89)
From my recollection of BASIC, INKEY$ has two main uses: (1) Enabling a clean abort of a running compute-bound program. (2) Busy-waiting for a time-interval. For case 1, UNIX provides signal handlers. For case 2, a read-with-timeout is more useful. Luckily, UNIX provides this as well. For long timeouts, it reduces to the case of a signal handler. For short timeouts, you need the USG termio, and set VMIN and VTIME. (3) Terminal emulators. For this case, you're better off with a multiway wait or two cooperating processes. Using an inkey$ type call to do this will just get you a bad name as a system hog. We just had to rip code like this out of microEmacs last year some time. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
jb@aablue.UUCP (John B Scalia) (01/07/89)
In <8332@ihpl.ATT.COM> Mike Knudsen makes a request for an INKEY type of
function similar to what is found in most BASICs.
The following code should solve your problem. It allows an INKEY() type
function that allows for multiple returns (ie. function keys), timeout if
user does not press a key, and the ability to wait forever if delay is given
as 0 :-) and the user must make some input. It will also trap every keyboard
stroke I've ever managed to give it. (At least I've not had a problem.)
--------- Cut here ----------
#include <termio.h>
#include <ctype.h>
int key_ret(deft, work) /* Generic Keyboard input like inkey */
int deft; /* Number of seconds to delay */
char work[]; /* character string to return result */
{
struct termio oldterm, curterm;
int timer, ret_code;
timer = deft * 10; /* timer = # of seconds to wait */
if (ioctl (0, TCGETA, &curterm) == -1)
return(-1); /* Not a terminal, abort */
oldterm = curterm;
curterm.c_lflag &= ~ICANON; /* canonical processing off */
if (timer == 0)
curterm.c_cc[VMIN] = 1;
else {
curterm.c_cc[VTIME] = timer;
curterm.c_cc[VMIN] = 0;
}
ioctl (0, TCSETA, &curterm);
ret_code = read (0, work, 10);
ioctl (0, TCSETA, &oldterm); /* restore terminal to old settings */
return (ret_code);
}
# End of function ----------------------
This works only if your function or definable keys produce less than 10
characters, of course you may change this to any number you'd want at the
read(n,C,10) statement. Please no flames about style, etc. I wrote this so
long ago I almost forgot where in fact I had put it.bzs@Encore.COM (Barry Shein) (01/08/89)
From: friedl@vsi.COM (Stephen J. Friedl) >In article <9281@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: >> Exactly. That's why I don't support standardization of curses-like >> interfaces. It's an idea whose time has gone. > >Doug, you are living in a dream world, one full of idealistic fantasy. >You may like your Blit, but for every one of you, there are at least >50,000 people with Wyse 50s at their desks. For the majority of these >people, a bitmapped interface would be massive overkill. I agree with Doug, you might be the one in a dream world. The point is investing the effort (read $$) in redoing the entire curses package, having it verified and accepted and getting it into common use takes a lot of time and money. I could stop right here and say if you're too cheap to buy new terminals why in the world would I cater to your needs for new software (ie. poverty sucks.) Better to learn to live with the current dumb terminal technology then wish (dream?) that someone else will invest that kind of effort. But the real point is that graphically oriented displays are coming down in price rapidly in the form of things like X terminals. There's already at least one brand selling for under $1K, PCs running decent graphical interfaces to remote systems should be commonplace soon and a floppy based, 640K, 286 PC is around $1K (ie. enough to run as a bitmapped-style terminal), all pretty close to dumb terminal prices and getting closer. Even very good (eg. 1Kx1K) X terminals are around $2K and I'll happily predict will approach $1K in a year or so, probably before the curses rewrite got out the door and into applications. Note that they're running both serial and ethernet interfaces. BUT, you ask, why would I throw out all those dumb terminals and replace them with these? It doesn't cost me anything (other than maintenance) to just keep my old stuff?! The answer is tautological but true: Software. Do you really want to buy *new* dumb terminals as you expand? Do you doubt that these new terminal users are going to be bringing in a whole new world of software which exploits these new terminals? How long will you want to support two incompatible software bases, buying the latest release of two new (wordprocessors, spreadsheets, editors, etc) every year and dealing with training and problems on both systems? When will the economics of that turn around and bite you? Put simply, try using an old paper terminal for a while and see how many needed tools don't even exist anymore or can't be bought (well, unix is pretty good at this, but only for the most basic chores, it certainly was frozen on this technology around a decade ago.) What happened to all the old paper terminals? We all threw them away, I remember seeing about 100 of them hauled away as junk a couple of years ago where I worked, perfectly good decwriter II's I would have killed for in 1978. I lived thru it with paper->crt's and people said the same sort of things (heck, I lived thru punch cards -> paper/interactive terminals, one dept STILL insisted on getting all their data on punch cards for years because, well, you could FEEL it or something.) I remember getting my head chopped off once for delivering an application that required a CRT and wouldn't work on a paper terminal, I think they called me a dreamer to think every tom, dick and harry would have a crt, ever. I think Lear Siegler introduced their $795 ADM-3A around three months later and that was the end of that argument. Besides, you see, NAIVE users prefer paper terminals because it lets them look back at what they did and re-enter things if necessary, only a sophisticated programmer-type can deal with things running off the screen all the time (anyone remember that argument? Ah, the naive user, s/he always wins the battle...) -Barry Shein, ||Encore||
bill@twwells.uucp (T. William Wells) (01/08/89)
In article <915@husc6.harvard.edu> wen@husc4.UUCP (A. Wen) writes:
: #include <ioctl.h>
:
: char inkey()
: {
: int count=0;
:
: ioctl(0,FIONREAD,&count);
: return(count?getchar():NULL);
: }
Unix chauvinist!
Not only that, but it's wrong. The function had better have a return
value of int and return EOF or some other value that is guaranteed to
not be a valid character.
And it's not going to work if the attached terminal is line oriented.
Presuming, of course, that the programmer has verified that the
opened file really is a terminal....
The inkey function is almost never as trivial is y'all would like.
When it can be done at all.
---
Bill
{ uunet!proxftl | novavax } !twwells!billmcdonald@uxe.cso.uiuc.edu (01/08/89)
>From my recollection of BASIC, INKEY$ has two main uses:
/* (long discussion deleted) */
The important point is that some such function should be a
STANDARD C (ANSI C) function, not an operating system dependent
kludge. It is obviously too late to get it done right this time
around, but next time .... PLEASE!ka@june.cs.washington.edu (Kenneth Almquist) (01/09/89)
cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes: > While curses was a Berkeley invention, it has been radically modified > at AT&T, including the development of terminfo, ... Well, my memory is pretty fuzzy here, but I was under the impression that AT&T had nothing to do with the original development of the terminfo version of curses, although Mark Horton did a lot of work on it after AT&T picked up the code. I recall that the code was copyrighted by Pavel Curtis (or some such person), and if it had been developed by AT&T then AT&T or Bell Labs would be the owner of the copyright. Anyone know for sure? Kenneth Almquist
seanf@sco.COM (Sean Fagan) (01/09/89)
In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: [about inkey()] >The important point is that some such function should be a >STANDARD C (ANSI C) function, not an operating system dependent >kludge. It is obviously too late to get it done right this time >around, but next time .... PLEASE! It's kind of hard to make in OS independent when there are some operating systems that just *cannot* do the type of thing you want, or have so much overhead in doing it that it's not worth it. For example, NOS on a CDC Cyber 170-state machine: to do I/O, you normally tell a peripheral processor, which swaps you out of main memory until it has a line of TTY input, at which point it rolls you back into memory, with the line automagically put into your buffer. To do what inkey$ in BASIC does, you would need single-character I/O, which "normal" users cannot get in NOS. And, yes, there are at least 2 C compilers for NOS, so it is an issue. -- Sean Eric Fagan | "Merry Christmas, drive carefully and have some great sex." seanf@sco.UUCP | -- Art Hoppe (408) 458-1422 | Any opinions expressed are my own, not my employers'.
peter@ficc.uu.net (Peter da Silva) (01/10/89)
In article <225800106@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > >From my recollection of BASIC, INKEY$ has two main uses: > /* (long discussion deleted) */ > The important point is that some such function should be a > STANDARD C (ANSI C) function, ... You obviously didn't pay attention to me. I just got through saying that INKEY$ is an extremely infeccient and CPU-intensive way of operating under an operating system like UNIX. It should certainly not be made part of 'C', just because of this little inconvenient fact. Any time you want to do INKEY$, stop and ask yourself what you're really doing. You may very well find that there are better tools... available and portable. Look up signal(), and meditate on multitasking. > ... not an operating system dependent > kludge. INKEY is an operating-system dependent kludge. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
bill@twwells.uucp (T. William Wells) (01/10/89)
In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
: The important point is that some such function should be a
: STANDARD C (ANSI C) function, not an operating system dependent
: kludge. It is obviously too late to get it done right this time
: around, but next time .... PLEASE!
And to repeat what has been said by many: IT CAN'T BE DONE!
A C compiler can't provide this function if the OS doesn't have the
facility.
And many terminals are incapable of transmitting characters as they
are typed.
---
Bill
{ uunet!proxftl | novavax } !twwells!billswilson%thetone@Sun.COM (Scott Wilson) (01/11/89)
In article <310@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >: The important point is that some such function should be a >: STANDARD C (ANSI C) function, not an operating system dependent >: kludge. It is obviously too late to get it done right this time >: around, but next time .... PLEASE! > >And to repeat what has been said by many: IT CAN'T BE DONE! > >A C compiler can't provide this function if the OS doesn't have the >facility. This argument is very similar to one I started some time ago related to echo/no echo on input, etc. The point of standard libraries is to smooth over OS dependencies to provide a uniform interface. If inkey() cannot be provided for on some systems, aren't there other operations mandated by the Standard that are just as hard to provide? For example, what about the legal modes passed to fopen()? Aren't there some systems where you simply can't open a file for simultaneous reading and writing? Or open for writing at the end of a file? What about fseek(), couldn't that be potentially very inefficient to implement on some brain-damaged systems? I don't know the answers to these questions. I guess what I'm wondering is: are there operations already part of the Standard that are there for historical reasons (i.e., it has always existed for most implementations) that would be rejected if it was recommended as a new feature because it was "too operating system dependent?" -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
chip@vector.UUCP (Chip Rosenthal) (01/11/89)
In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>From my recollection of BASIC, INKEY$ has two main uses: >/* (long discussion deleted) */ >The important point is that some such function should be a >STANDARD C (ANSI C) function No, that isn't the important point. Such a procedure is generally used for busy loops, and this is a bad idea. If you are waiting for a keystroke, then use c_cc[VMIN]=1. If you are waiting for a one of a number of assynchronous events, then fork processes to block on the various events and signal the parent to handle it. Since busy waiting is a bad idea, so is formalizing it in a standard. -- Chip Rosenthal chip@vector.UUCP | Choke me in the shallow water Dallas Semiconductor 214-450-5337 | before I get too deep.
mcdonald@uxe.cso.uiuc.edu (01/11/89)
I said this: >> The important point is that some such function should be a >> STANDARD C (ANSI C) function, ... peter@ficc.uu.net replies: >You obviously didn't pay attention to me. I just got through saying that >INKEY$ is an extremely infeccient and CPU-intensive way of operating under >an operating system like UNIX. It should certainly not be made part of >'C', just because of this little inconvenient fact. Any time you want to >do INKEY$, stop and ask yourself what you're really doing. You may very >well find that there are better tools... available and portable. Look up >signal(), and meditate on multitasking. And I say that peter@ficc.uu.net doesn't know what he is talking about. I read from by Basic manual (I do that because I never use Basic. The equivalent function in Microsost C is if(kbhit())(if ((c1=getch()) == 0)c2=getch()).) that v$=INKEY$ returns one character read from the keyboard. If no character is pending in the keyboard buffer, a null string is returned. This implies that it does not wait for input, but rather returns at once. If there is something there, the program acts on it. If nothing is there, and the program is in the middle of doing something useful, like a compute-bound task, it continue computing. If it has nothing more to do at the moment, and needs input to continue, it THEN calls the function (getch() in MSC) which reads from the keyboard without echoing, and which WAITS for input. In a multitasking environment like Desqview or Windows, this yields to another process. To see an example of code with this in it, look in my TeX screen preview program dvivga (routines dvivga.c and prtpage.h) available by anonymous ftp from b.scs.uiuc.edu. I see not the tiniest reason that the functions kbhit() and getch() couldn't be implemented on any reasonable system, including Unix or VMS. I've even written a kbhit() for VMS (ugh! I'll bet Unix will be easier.) The problem on multitasking systems arises when more than one type of asymchronous event must be detected while waiting (such as both keyboard and mouse events.) Then the only general solution that works on both multitasking and normally non-multitasking systems is to call an operating system sleep() routine to wait a decent interval, then retest.
mcdonald@uxe.cso.uiuc.edu (01/11/89)
>In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >[about inkey()] >>The important point is that some such function should be a >>STANDARD C (ANSI C) function, not an operating system dependent >>kludge. It is obviously too late to get it done right this time >>around, but next time .... PLEASE! >It's kind of hard to make in OS independent when there are some operating >systems that just *cannot* do the type of thing you want, or have so much >overhead in doing it that it's not worth it. For example, NOS on a CDC >Cyber 170-state machine: to do I/O, you normally tell a peripheral >processor, which swaps you out of main memory until it has a line of TTY >input, at which point it rolls you back into memory, with the line >automagically put into your buffer. To do what inkey$ in BASIC does, you >would need single-character I/O, which "normal" users cannot get in NOS. >And, yes, there are at least 2 C compilers for NOS, so it is an issue. Things like NOS are why I WANT it IN THE STANDARD!!! If you only get a line at a time YOU CAN'T, ABSOLUTELY CAN'T write decent software. The impossibility of writing a decent editor is one reason we no longer use CDC computers here. Why can't "normal" users on NOS do what I would call "normal" io? If I were looking for a computer today, I would not even CONSIDER one that can't do that. If a manufacturer wants to make a computer that has severe IO problems like that, he should have a multiprocessor system where directly connected users CAN do it, offloading only the more compute bound parts of a task on the more remote sections of hardware. If your OS can't do single character IO ---- FIX IT! Doug McDonald
swilson%thetone@Sun.COM (Scott Wilson) (01/12/89)
In article <686@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes: >In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >>>From my recollection of BASIC, INKEY$ has two main uses: >>/* (long discussion deleted) */ >>The important point is that some such function should be a >>STANDARD C (ANSI C) function > >No, that isn't the important point. Such a procedure is generally used >for busy loops, and this is a bad idea. If you are waiting for a keystroke, >then use c_cc[VMIN]=1. If you are waiting for a one of a number of >assynchronous events, then fork processes to block on the various events >and signal the parent to handle it. Who said anything about UNIX? This is comp.lang.c not comp.lang.c.on.unix. And yes C does run in environments other than UNIX which is probably why the original poster would like to see inkey() standardized. And even if this was comp.lang.c.on.unix why assume everyone is using a UNIX that has SV style tty drivers? Sorry for being snotty, but I get tired of people spitting out "simple" solutions that don't necessarily make sense in the scope of a newsgroup. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
prc@maxim.ERBE.SE (Robert Claeson) (01/12/89)
A discussion about a BASIC-derived INKEY$ function that reads the keyboard and returns the next character if one is available, or returns NULL or EOF otherwise. Some people thinks such a function should be in the ANSI C standard. To this, Chip Rosentahl (chip@vector.uucp) responds: > ...Such a procedure is generally used > for busy loops, and this is a bad idea. ...to which I completely agree. He then goes on to write: > If you are waiting for a keystroke, then use c_cc[VMIN]=1. ...which is specific to System V. The intent was to standardise on a system-independent interface to that function. > If you are waiting for a one of a number of asynchronous events, > then fork processes to block on the various events and signal the > parent to handle it. This is generally a good idea, but easily becomes system dependent as well. This technique is most common in System V and slightly less common in BSD (where the select system call can be used in most cases) and uncommon in most other operating systems. > Since busy waiting is a bad idea, so is formalizing it in a standard. Agreed. But what about having a function that returns the status of the input queue (or possibly the number of characters waiting in the input queue) and another function to do a blocking, single character read? Or, even better, have a system-independent interface to various mode setting operations. I think this is what the termios calls in the POSIX draft standard are all about. One can in general not cover all types of input devices (an asyncronus terminal is much differnet from a punched-card reader), but it would certainly be possible to define a system-independent interface for a certain class of terminals. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden "No problems." -- Alf Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE BITNET: rclaeson@ERBE.SE
jbayer@ispi.UUCP (Jonathan Bayer) (01/13/89)
In article <11067@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes: >In article <443@marob.MASA.COM>, daveh@marob.MASA.COM (Dave Hammond) writes: >> >> Are you saying that a (relatively) high-priced, ethernet-connected [ deleted ] > >First off, these machines are now available for under $2000. >Examples are Acer's Xerbra, a terminal with an ethernet connector and >an X server in rom, and Atari ST's running NeWS with some help from >a BSD box. Sorry. I can't justify the cost to my customers to spend upwards of $ 2000 per terminal when the cost of a regular character-oriented terminal is now around $ 300. There are many applications around which do not have or need any graphics abilities. There is no need to run them on a bit-mapped terminal. Additionally, there are many systems out in the field in which the users are using only one or two applications. If these applications are character oriented why should they have to spend the money for an expensive terminal. The difference in cost is between $ 1000 and $ 1500. When you multiply this by the number of terminals in an office, the cost starts to become prohibitive. JB -- Jonathan Bayer "The time has come," the Walrus said... Intelligent Software Products, Inc. 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi
cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) (01/13/89)
In article <225800108@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > Things like NOS are why I WANT it IN THE STANDARD!!! If you only get > a line at a time YOU CAN'T, ABSOLUTELY CAN'T write decent software. > The impossibility of writing a decent editor is one reason we no > longer use CDC computers here. Why can't "normal" users on NOS do > what I would call "normal" io? If I were looking for a computer today, > I would not even CONSIDER one that can't do that. If a manufacturer > wants to make a computer that has severe IO problems like that, he > should have a multiprocessor system where directly connected users > CAN do it, offloading only the more compute bound parts of a task > on the more remote sections of hardware. > > If your OS can't do single character IO ---- FIX IT! Er, um, ah...what makes you assume that all C programs run on machines which have any idea of a 'keyboard', or have anything like an 'operating system'? I'm typing this on a 5620 terminal, which certainly has a C compiler, but has an `operating system' which would hardly be adequate for any kind of stand-alone computer. Let's not forget about phone switching equipment, the computers on which a large fraction of the C code ever written is running. The stdio libraries guarentee that you can pump data back and forth between the 'stdin', 'stdout', 'stderr', and 'files', but who said any of these were keyboards, screens, or disks? The PostScript language has all the same ideas, but most printers implement 'std(in|out|err)' as the serial port, and 'files' as blocks of memory. The same language running as part of NeWS (a PostScript based windowing system), 'std(in|out)' to the socked which connected to the window server, 'stderr' to the stderr of the server, and files do disk files. > If your OS can't do single character IO ---- FIX IT! I totally agree here, but what does it have to do with the C language?!? -- Name: Christopher J. Calabrese Brained loaned to: AT&T Bell Laboratories, Murray Hill, NJ att!ulysses!cjc cjc@ulysses.att.com Quote: ``I'm sure Henry Spencer will have a .signature on this soon.''
bill@twwells.uucp (T. William Wells) (01/13/89)
In article <225800107@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
: I see not the tiniest reason that the functions kbhit() and getch()
: couldn't be implemented on any reasonable system, including Unix or
: VMS. I've even written a kbhit() for VMS (ugh! I'll bet Unix will be easier.)
Well, if we are going to toss around words like "reasonable" we should
not mean them to be equivalent to "something I'd want to use". There
are plenty of systems around where INKEY$ is not possible. Either
because the OS does not provide any way to implement the function or
because the function can not be implemented on the hardware.
(Hey guys, this looks like another candidate for the most
frequently.... Most frequently what, I'm not saying :-)
---
Bill
{ uunet!proxftl | novavax } !twwells!billschwartz@shire.cs.psu.edu (Scott Schwartz) (01/13/89)
In article <225800107@uxe.cso.uiuc.edu>, mcdonald@uxe writes: >I see not the tiniest reason that the functions kbhit() and getch() >couldn't be implemented on any reasonable system, including Unix or >VMS. I've even written a kbhit() for VMS (ugh! I'll bet Unix will be easier.) On some systems, like VM/CMS, terminals only send a line at a time. In other words, #define inkey getchar is the best you can do, and even that would require doing an fgets(). Is that "reasonable"? Don't thank ANSI, thank IBM. -- Scott Schwartz <schwartz@shire.cs.psu.edu>
peter@ficc.uu.net (Peter da Silva) (01/14/89)
In article <84920@sun.uucp>, swilson%thetone@Sun.COM (Scott Wilson) writes: > Who said anything about UNIX? This is comp.lang.c not comp.lang.c.on.unix. > And yes C does run in environments other than UNIX which is probably why > the original poster would like to see inkey() standardized. Well, no. 'C' standards should be based on the availability and appropriate- ness of the operation on a wide variety of operating systems. The only ones for which inkey$ is appropriate are those derived from CP/M and other hobbyist systems on which busy-waiting is reasonable. Everyone else requires mechanisms that are at wildly different... Let's look at busy-waiting to monitor two event streams... For the Macintosh, for example, the whole tty-style user interface (and inkey$) is superseded by Get/WaitNextEvent. On the Amiga, you just put out a concurrent wait on two signals or message ports. On UNIX you fork() and put out two read()s. And so on. Inkey() can be implemented on most of these systems, but it shouldn't... any more than "near" and "far" should be included in the standard. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
maujt@warwick.ac.uk (Richard J Cox) (01/15/89)
In article <225800107@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > > >This implies that it does not wait for input, but rather returns at once. >If there is something there, the On UNIX - cbreak mode. Characters are passed to the buffer immediately (no newline needed) and can be read with getc() or similar. To go into cbreak mode you use one of the ioctl() calls. Nothing is echoed to the terminal, so you have to do this explicitly (I think). - RC /*--------------------------------------------------------------------------*/ JANET: maujt@uk.ac.warwick.cu BITNET: maujt%uk.ac.warwick.cu@UKACRL ARPA: maujt@cu.warwick.ac.uk UUCP: maujt%cu.warwick.ac.uk@ukc.uucp Richard Cox, 84 St. Georges Rd, Coventry, CV1 2DL; UK PHONE: (0203) 520995
jbayer@ispi.UUCP (Jonathan Bayer) (01/15/89)
In article <310@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >And many terminals are incapable of transmitting characters as they >are typed. I don't know about what terminals you are using, but most (if not all) serial terminals ARE capable of transmitting characters as they are typed. In fact, as far as I know the normal mode for most terminals since they have to be put into a block mode to hold characters before transmitting. JB -- Jonathan Bayer "The time has come," the Walrus said... Intelligent Software Products, Inc. 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi
paul@athertn.Atherton.COM (Paul Sander) (01/15/89)
In article <9281@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <11064@ulysses.homer.nj.att.com> cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes: > >Besides, who uses a character terminal any more :-) :-) :-) :-) > > Exactly. That's why I don't support standardization of curses-like > interfaces. It's an idea whose time has gone. Hey, wait a minute. There are an awful lot of people still using character terminals. Some of my company's customers rely on them. I've seen installations where literally hundreds of programmers have had to share bitmap terminals that could be counted on the knuckles of one finger. No joke! And they make up for it by using ASCII terminals. And I make my living developing user interfaces for these people. There used to be a saying that "not all the world's a VAX." Perhaps we should also remember that "not all the world's a Sun/Apollo/Mac/insert- favorite-desktop-workstation-with-bitmap-terminal-here." -- Paul Sander (408) 734-9822 | Do YOU get nervous when a paul@Atherton.COM | sys{op,adm,prg,engr} says {decwrl,sun,hplabs!hpda}!athertn!paul | "oops..." ?
dave@westmark.UUCP (Dave Levenson) (01/15/89)
In article <686@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: > In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >>From my recollection of BASIC, INKEY$ has two main uses: ... > >The important point is that some such function should be a > >STANDARD C (ANSI C) function ... > No, that isn't the important point. Such a procedure is generally used > for busy loops, and this is a bad idea... > ...If you are waiting for a one of a number of > assynchronous events, then fork processes to block on the various events > and signal the parent to handle it. ... > Since busy waiting is a bad idea, so is formalizing it in a standard. Waiting for events (such as keystrokes) is not, in itself, a bad idea! A standard library function to do it is a good idea. Looping within a process _is_ a bad idea in the UNIX operating system, but the C language is not supposed to be operating system specific. There are operating systems where forking a process is not possible (are you listening, Microsoft?). A standard event_wait() might be implemented differently where fork() is defined, but ought to exist, in some form, in the standard library for all supported environments, no? -- Dave Levenson Westmark, Inc. The Man in the Mooney Warren, NJ USA {rutgers | att}!westmark!dave
seanf@sco.COM (Sean Fagan) (01/15/89)
[note the followup. This isn't a C-only subject any more] [also, although it wasn't indicated, '>>' is me (seanf@sco.com)] In article <225800108@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >> >>For example, NOS on a CDC >>Cyber 170-state machine: to do I/O, you normally tell a peripheral >>processor, which swaps you out of main memory until it has a line of TTY >>input, at which point it rolls you back into memory, with the line >>automagically put into your buffer. To do what inkey$ in BASIC does, you >>would need single-character I/O, which "normal" users cannot get in NOS. > >>And, yes, there are at least 2 C compilers for NOS, so it is an issue. > >Things like NOS are why I WANT it IN THE STANDARD!!! If you only get >a line at a time YOU CAN'T, ABSOLUTELY CAN'T write decent software. >The impossibility of writing a decent editor is one reason we no >longer use CDC computers here. Why can't "normal" users on NOS do >what I would call "normal" io? If I were looking for a computer today, >I would not even CONSIDER one that can't do that. If a manufacturer >wants to make a computer that has severe IO problems like that, he >should have a multiprocessor system where directly connected users >CAN do it, offloading only the more compute bound parts of a task >on the more remote sections of hardware. >If your OS can't do single character IO ---- FIX IT! Point 1: Most of the software I write doesn't use single-character I/O, unless you count ^C (to interrupt) as scIO, in which case I believe NOS can be set up to do the same thing. Based on what you say, the following programs aren't "decent software": adb ar as awk basename cal cat cc chgrp chmod chown chroot cp date dc dd df diff du echo ed egrep fgrep file find fsck grep head ipcrm ipcs ls make mkdir mv nm passwd ps pwd ranlib rm rmdir sed sh sleep sort strings strip stty sync tar time touch tr tsort wc who at bc calendar ctags cxref finger ftp get lex lint mail rcp sdb yacc *NONE* of these require scIO, and would work *just fine* on systems that don't have it. Point 2: There is a damned good reason why NOS doesn't have scIO. scIO is, no matter how you do it, going to slow down the processor. Everything you interrupt the cpu, you are slowing down a program somewhere. If, on the other hand, you do what NOS does, you only have to interrupt the processor when you roll a job back into memory, at which point it already has the input line in memory, and can just play with it at it's leisure. Why do you think that there are "smart" serial cards for PC's running Unix? You can, if you really want to, get scIO on a Seymour-Cray-designed machine, but talk to people running GNU emacs on a Cray-2, and ask them what it does to system performance... Point 3: (I've copied the lines from above, so don't worry, he didn't repeat himself.) >The impossibility of writing a decent editor is one reason we no >longer use CDC computers here. Why can't "normal" users on NOS do There is a very decent editor under NOS. It's called FSE (Full Screen Editor). Yes, it's full screen. No, it doesn't use scIO. What it does is go through the input line, looking for escape characters and commands, processes it all internally, and then dumps what it thinks the screen should look like. It's a very nice editor (although I would like to see it get regular expressions for searching and replacing), and it's possible to get 50-60 people using it at once, on the same machine. Try this with GNU emacs on anything other than an Amdahl. Point 1, revisted, with shades of Point 2: Get a Unix machine, with sources to the tty driver. Rewrite the tty driver so that it copies an entire line of text to the process. Get a 630 (aka BLIT terminal), and run sam on it. I believe that Doug Gwyn has commented enough about sam and a 630. Believe it or not, the Unix-end of sam is a line-oriented editor. Are you saying that sam is not decent software? Face it: Unix is slow, and will always be slow until people start doing their ports properly, looking for speed, and designing it for the target system entirely. NOS, on the other hand, is fast, because it was designed properly. This does not mean that I prefer NOS to Unix. However, I have a little test for you. Get on your favorite Unix or VMS machine (say, a top-of-the-line VAX). Write a nice little FORTRAN program that does lots of file-io, or even user-io. I'll port the program to a CDC Cyber 170/750, a 15-20 year old machine, and it will probably run faster, even though the 750 is, by Cyber standards, a bit slow (it's only a 5-6 MFLOPS machine, mainly due to the 400ns ram). Or, I'll port it to a Cyber 180/960, running in 170 mode, and it will still probably beat the VAX. Why? Because the OS was designed to do that type of thing, while VMS and Unix weren't. Try thinking what a feature does to an operating system before you demand it. You might find that it's better, in the long run, to leave it out and try a different approach (a la FSE). I think that's most of what I want to say. I, also, used to think that scIO was necessary, until I started working on NOS, and found out the reasons. Other than vi, rn, and emacs, I don't use scIO programs anymore, and I can get the same functionality for those without it. I would also like to point out that it's possible to port Unix in such a way that typing a character on the keyboard doesn't interrupt the CPU, but most people don't bother doing so. Add that to the list of Unix gripes. -- Sean Eric Fagan | "May the forces of evil become confused on the way to seanf@sco.UUCP | you house." -- George Carlin (408) 458-1422 | Any opinions expressed are my own, not my employers'.
leech@alanine.cs.unc.edu (Jonathan Leech) (01/15/89)
In article <411@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >In article <310@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >>And many terminals are incapable of transmitting characters as they >>are typed. >I don't know about what terminals you are using, but most (if not all) >serial terminals ARE capable of transmitting characters as they are >typed. IBM 3270-style block mode terminals have this "feature". I've used Unix (Amdahl UTS/580) on such terminals, and it's painful. The usual editors don't work, ksh loses, etc (but hey! you get hardware pagination). There are a *lot* of block mode terminals in the world. Fortunately, most of them aren't connected to Unix systems. Some of the same problems can arise when working over packet networks (X.25) that don't support break after every character. You wouldn't want them to in any case, since charging is frequently on a per packet basis :-) Followups to comp.terminals. -- Jon Leech (leech@cs.unc.edu) __@/ ``My goal is simple. It is complete understanding of the universe, why it is as it is and why it exists at all.'' - Stephen Hawking
guy@auspex.UUCP (Guy Harris) (01/17/89)
>On UNIX - cbreak mode. Characters are passed to the buffer immediately >(no newline needed) and can be read with getc() or similar. ... >Nothing is echoed to the terminal, so you have to do this explicitly (I >think). Incorrect. Turning echoing off and turning canonicalization off are two separate operations on all versions of UNIX I know of; in practice, most programs that turn canonicalization off also turn echoing off and do the echoing themselves, but that's not required.
bga@raspail.UUCP (Bruce Albrecht) (01/17/89)
In article <2075@scolex>, seanf@sco.COM (Sean Fagan) writes: > In article <225800108@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >> > >>For example, NOS on a CDC > >>Cyber 170-state machine: to do I/O, you normally tell a peripheral > >>processor, which swaps you out of main memory until it has a line of TTY > >>input, at which point it rolls you back into memory, with the line > >>automagically put into your buffer. To do what inkey$ in BASIC does, you > >>would need single-character I/O, which "normal" users cannot get in NOS. > > > >>And, yes, there are at least 2 C compilers for NOS, so it is an issue. > > > >Things like NOS are why I WANT it IN THE STANDARD!!! If you only get > >a line at a time YOU CAN'T, ABSOLUTELY CAN'T write decent software. > >The impossibility of writing a decent editor is one reason we no > >longer use CDC computers here. Why can't "normal" users on NOS do > >what I would call "normal" io? If I were looking for a computer today, > >I would not even CONSIDER one that can't do that. If a manufacturer > >wants to make a computer that has severe IO problems like that, he > >should have a multiprocessor system where directly connected users > >CAN do it, offloading only the more compute bound parts of a task > >on the more remote sections of hardware. > >If your OS can't do single character IO ---- FIX IT! > Anyone who thinks that "normal" users of NOS can't do single character I/O, is either using something other than CDC communications processors, or didn't bother to look at the CDC manuals. We have supported single character I/O for at least 5 years, if not longer, although it requires some setup by the user application. CDC's position, and I think rightly so, is that single character I/O is such a drain on ANY system's resources that it should not be used unless absolutely necessary. (BTW if you were looking for a computer today, CDC would sell you a 180 running NOS/VE, and there is no development done for NOS any more.) > I think that's most of what I want to say. I, also, used to think that scIO > was necessary, until I started working on NOS, and found out the reasons. > Other than vi, rn, and emacs, I don't use scIO programs anymore, and I can > get the same functionality for those without it. > > I would also like to point out that it's possible to port Unix in such a way > that typing a character on the keyboard doesn't interrupt the CPU, but most > people don't bother doing so. Add that to the list of Unix gripes. In VX/VE, CDC's Unix shell for NOS/VE, input is normally line at a time. When a program "needs" scIO, such as VI, it instructs the front-end communications processor to send input a character at a time. I personally prefer the CDC screen editors that are not scIO, as I find them easier to use than the vi input/command modes. Another reason why CDC is against using scIO is that it doesn't work very well in a distributed computing environment. If the scIO is on a single computer directly connected to the terminal (or is the computer), it works very well, and the character echo times are usually measured in a tenth of a second or less. On the other hand, if you are connected to a large network, and some of the computers you are using are located thousands of miles away, the character echo time can be .75 seconds or more, which most people find unacceptable. Try running vi or Emacs when dialed into Telenet, and from there through a second network, and you'll understand why using terminal echo and an editor that doesn't use scIO has its advantages. Because single character I/O is not supported by some terminals (block mode only), some networks (not available, or too expensive), and some operating systems, I don't think routines to support it belong in the set of routines required to exist in order for a C implementation to be standards-compliant. If there's a second set of standard routines, that are available at the discretion of the implementer, that's where they belong.