mmcp@sdsu.UUCP ( mmcp) (06/13/89)
Hi folks,
I am running UNIX as HP-UX 6.2 on a 9000 series 300 computer; and I
am trying to do terminal i/o which requires the ability to flush an input
buffer before I post a read. To do this, I am using the following code
outline:
#include <termio.h>
main()
{
...stuff
fd = open( "/dev/tty", O_RDONLY );
ioctl( fd, TCFLSH, 0 ); /* flush input buffer */
c = getc( stdin ); /* stdin and fd both
control terminal */
...more stuff
}
Is this enough to do what I want? I have also tried doing
this by fdopen()ing a stream off of fd and passing this to fgetc(). I am
sometimes getting this to work, but to unpredicatable results. Part of the
"stuff" code is a signal handler which is waking up every 500000 milliseconds
and incrementing a variable; nothing more. I looked around for ways to flush
stdin, and this was all I could come up with after looking at termio(7).
Remember, I am trying to erase the characters from the input buffer. I don't
want any characters there until I actually post a read.
Any help would be appreciated.
Syd Logan
San Diego State University
rml@hpfcdc.HP.COM (Bob Lenk) (06/14/89)
> fd = open( "/dev/tty", O_RDONLY ); > > ioctl( fd, TCFLSH, 0 ); /* flush input buffer */ > > c = getc( stdin ); /* stdin and fd both > control terminal */ The most likely cause of your problem is that the buffered input that sometimes causes problems is being buffered by the standard I/O library, not the terminal driver. TCFLSH bypasses the standard I/O library. You can turn off standard I/O buffering with setbuf(3S) or setvbuf(3S), or use read(2) directly instead of the standard I/O library. If you do use the standard I/O library, it would be cleaner to use a file descriptor and FILE pointer that are clearly related (one derived from the other with fdopen(3S) or fileno(3S)). This code could behave strangely if standard input is redirected away from the controlling terminal. > Part of the > "stuff" code is a signal handler which is waking up every 500000 milliseconds A second possibility is that this signal is interrupting some call and causing it to fail. Some ways to deal with this: - Check the returns from all system calls and library calls. EINTR errors indicate this problem. - Block the signal (presumably SIGALRM) around calls that could be affected in this way (see sigblock(2)). - Have your signal handler specify that interrupted system calls be restarted instead of interrupted (see sigvector(2)). Bob Lenk rml@hpfcla.hp.com hplabs!hpfcla!rml