jfjr@mitre-bedford.arpa (06/08/87)
This may be a trivial question to the wizards but I am a unix
novice (~3 months). I need to read a character from the terminal
without stopping a program. I have a program thats going to
do a lot of interesting things you wouldn't be interested in.
I want to give the user the ability to halt the processing
at any time - poke around the program and then resume processing.
While the program is doing its thing all sorts of terminal and
file i/o are happening. I have done this successfully and simply
on VMS using qio with the proper flag but I am having problems
doing it on Unix. I would rather not have to do this trick by
using a second process nor would I want to usurp Control-C.
I should qualify the "anytime" above. The program will be
(basically) a while loop. I would like to be able to check
at the top of the loop to see if the user has entered the
proper character - if he/she has then go into the special
snooping mode, if no character or the wrong character is entered
then ignore and continue with processing.
I really must say that Unix documentation compared to
VMS doesn't measure up( or maybe I am looking in the wrong
places if so enlighten me)
Thirster after knowledge
Jerry Freedman, Jr "If at first you don't succeed, lower your standards"
jfjr@mitre-bedford.arpa
(617)271-6248 or 8658 edw@ius2.cs.cmu.edu (Eddie Wyatt) (06/09/87)
In article <7749@brl-adm.ARPA>, jfjr@mitre-bedford.arpa (Freedman) writes: > > This may be a trivial question to the wizards but I am a unix > novice (~3 months). I need to read a character from the terminal > without stopping a program. I have a program thats going to > do a lot of interesting things you wouldn't be interested in. > I want to give the user the ability to halt the processing > at any time - poke around the program and then resume processing. > While the program is doing its thing all sorts of terminal and > file i/o are happening. I have done this successfully and simply > on VMS using qio with the proper flag but I am having problems > doing it on Unix. I would rather not have to do this trick by > using a second process nor would I want to usurp Control-C. > > I really must say that Unix documentation compared to > VMS doesn't measure up( or maybe I am looking in the wrong > places if so enlighten me) > > Thirster after knowledge > > Jerry Freedman, Jr "If at first you don't succeed, lower your standards" > jfjr@mitre-bedford.arpa > (617)271-6248 or 8658 The functions you want to look into are ioctl (i/o control) or stty (set tty). Do a "man 4 tty" to find what all the options to ioctl are. To do what you want to do : enable_quick_input() { struct sgttyb mode; int fd = fileno(stdin); gtty(fd, &mode); /* get old mode */ mode.sg_flags &= ~RAW; /* process special characters like ^H */ mode.sg_flags &= ECHO; /* make sure echo is on */ mode.sg_flags &= CBREAK; /* make characters available to process as soon as they are typed (this may disable cooked mode). */ stty(fd, &mode); /* set mode */ } I believe that will do it. To poll for input you can use select if you want. But that's a little slow so use ioctl(). int ready_to_read(fd) int fd; /* a file desciptor, not a FILE pointer here */ { int num; ioctl(fd,FIONREAD,(char *)&num); return(num > 0); } Which brings up a question. Does anyone know of a quicker way of determining if any characters are on a port other than using ioctl (select is slower, at least by what I have measured)? -- Eddie Wyatt e-mail: edw@ius2.cs.cmu.edu
mikep@ism780c.UUCP (06/11/87)
In article <7749@brl-adm.ARPA> jfjr@mitre-bedford.arpa (Freedman) writes: > >I need to read a character from the terminal >without stopping a program. > >Jerry Freedman, Jr "If at first you don't succeed, lower your standards" >jfjr@mitre-bedford.arpa >(617)271-6248 or 8658 Jerry, You didn't specify what version of UNIX (or even Xenix) that you were using. If you were using Xenix 3.X, for example, there is a rdchk() function that allows you to see if any characters are available on the input queue. Respond and you can get a little more detail. By the way, take a more detailed look at the tty section of devices and the ioctl() call in the ref. manual. These will help you. ps - Do you know a person by the name of Adolph Fejfar or Mike Corin who work for MITRE-Bedford, but at the Ft. Huachuca, AZ. site? Just curious to see how small a world it *actually* is... ------------------------------------------------------------------------------- The company and all my associates and friends and ESPECIALLY the government put me up to say all this useless trash. |=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=|=| MikeP sdcrdcf!\ "Some of my best friends are Bigots..." >-- ism780c!mikep seismo!/
stevesu@copper.UUCP (06/14/87)
In article <7749@brl-adm.ARPA>, jfjr@mitre-bedford.arpa (Freedman) writes: > I need to read a character from the terminal without stopping a > program. I have done this successfully and simply on VMS using qio > with the proper flag but I am having problems doing it on Unix. > > I really must say that Unix documentation compared to > VMS doesn't measure up... As several people have already mentioned, ioctl(FIONREAD) and select() are fairly general and somewhat portable solutions under Unix. You might have mentioned the specific qio options you used-- some of us Unix wizards have ventured off into VMS and lived to tell about it. If you were doing true asynchronous I/O, by using qio (as opposed to qiow) and specifying an AST completion routine, you may find some equivalents on Unix; look at fcntl(2), if you have it, specifically the FNDELAY and FASYNC options. Beware that these facilities are newer, buggier, less portable, and harder to use than the more mature parts of Unix. I won't defend Unix documentation, but I'll throw in a potshot at VMS--I'd find its documentation a lot easier to use if it had an index that was at all usable. I have _n_e_v_e_r in my entire life looked up a topic in a VMS index and found what I was looking for, even when I knew that I'd read exactly what I was looking for once before. (Please, no Unix vs. VMS holy wars in response to this.) Steve Summit stevesu@copper.tek.com