[comp.sys.hp] terminal i/o

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