unix terminal i/o (summary)

[Robert Goldman]

	I am very grateful to everyone on the net who responded to my
requests for information about unix terminal i/o.  Here is a brief summary
of the information which I received.
	The questions I asked were:  what is curses?  where is it
documented, and how does one get the documentation?  what systems does it
work under?  which terminals does it and does it not support? and how can
one read no-wait input off the terminal?

what is curses?
	A terminal-independant i/o library for unix.

where is it documented, and how does one get the documentation?
	this was the real toughie.  the man page for curses gives the
following reference:  SEE ALSO 
_Screen_Updating_and_Cursor_Movement_Optimization:_A_Library_Package_, Ken
Arnold. 
	I had no luck getting hold of this.  I called Bell labs, and they
didn't have it, I called UCB and they couldn't tell their tushies from their
elbows, and I finally gave up when I found curses documentation in a
friend's copy of the XENIX documentation.  That's a pretty good source,
albeit cluttered by a ridiculous number of repetitions of the initials
"IBM."  Here are some suggestions which others gave; I hope you have better
luck than I did:
It comes with BSD documentation (Volume 2c I think) and SVR2 (called
"curses/terminfo" in the Programmer's Guide).  You can get SV doc by
calling 1-800-828-UNIX I believe.
						Michael Baldwin
						AT&T Bell Laboratories

another person (whose message I am embarrassed to admit that I lost),
suggested that I contact UCB, Corey Hall.  Unfortunately, they were the
people who didn't know . . .  In fact, UCB didn't seem to know where Corey
Hall WAS.
another person suggested that USENIX might have the documentation.


what systems does curses work under?
	BSDs 4.1 and 4.2, SysV and Xenix.  I don't know about the other
clones, but I imagine so.

what terminals does it support?
	most people said that it supported every imaginable one.


how can one tell if there are keystrokes waiting to be interpreted? is there
a portable method?
	To answer the second question first, NO.  People sent me various
different methods for different unix versions.  Here is a quick synopsis:
BSD 4.1 (mine):
	use an ioctl call with the constant FIONREAD.  This will tell how
many bytes are unread in a given file. (see man ioctl & man tty)

BSD 4.2:
	as per above, or
   Either use the same method as in 4.1BSD or use non-blocking reads.

   # include <fcntl.h>

   ...
     i = fcntl(0,F_GETFL, 0);
     fcntl(0, F_SETFL, i | FNDELAY);

   This makes reads non-blocking. If a read would block, it returns -1,
   with EWOULDBLOCK in errno.
				(from Ceriel Jacobs, Vrije Universiteit,
					Amsterdam)

sysV and sysIII:
   In these unix systems, non-blocking reads are also available, but are
   a little different. I don't have the documentation on that, but I believe
   the FNDELAY above, is called O_NDELAY here, and if a read would block,
   it returns 0.
			(also from Mr./Ms. Jacobs [sorry about that!])

older unices:
	wierd.  here are some tips from respondents:
There is no way to do it in V7 apart from poking
around /dev/kmem, which is not terribly portable.

Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall
-
V7: Officially impossible. If you have source, though, I can send
you the code for the FIONREAD call (see below), which is easy to
insert into a V7 kernel.
Also, there is a bug in the tty driver, allowing you to do this. It
works as follows:
If you set the mode to RAW or CBREAK, using the non-wait ioctl (TIOCSETN),
and there is still a line terminator in the input buffer (LF, or
whatever), whenever you read() after that, you will get end of file if
there is no char available. If you drop me a line at htsa!jack I'll
send you a code fragment.
					Jack Jansen, jack at mcvax.UUCP
				pwa-b!utah-gr!seismo!mcvax!jack (Jack Jansen)
-
Well, you can use a FIONREAD ioctl, but that is not portable.  
The alternative is to send yourself an alarm, start a getchar(), and
if the alarm arrives before a character, continue on your merry way.

-- 

					Don Davis
					JHU/APL
				...decvax!harpo!seismo!umcp-cs!aplvax!ded
				...rlgvax!cvl!umcp-cs!aplvax!ded


	
	Again, my greatest thanks to all of you who answered my query.

					Robert Goldman
					MultiMate International

None of the opinions above are binding on MultiMate, they are my own.
However, I imagine that MultiMate is officially grateful, as am I.