Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!jpusa1!news
From: news@jpusa1.UUCP (usenet)
Newsgroups: comp.unix.xenix
Subject: termio under SCO Xenix
Message-ID: <659@jpusa1.UUCP>
Date: 18 Jan 88 23:47:33 GMT
References: <2113@chinet.UUCP>
Reply-To: stu@jpusa1.UUCP (Stu Heiss)
Followup-To: comp.unix.xenix
Organization: JPUSA - Chicago, IL
Lines: 38
Summary:

Expires:


In article <2113@chinet.UUCP> clif@chinet.UUCP (Clif Flynt) writes:
-This is either a bug in my understanding of termio, or a bug in SCO's
-implementation.  I'd be happy to hear either confirmed, since I've 
-found a workaround.
-
-The situation is that I need to watch keystrokes coming in from console,
-and distinguish the difference between a function key ( '<ESC> [ G' for
-example) and an escape.  My thought was that I'd set the VMIN and VTIME
-parameters in termio, turn off ICANON, and if I timed out, then I'd
-recieved a bare escape, not the start of a function key.
-
-So, I tried:
-
-nterm.c_cc[VMIN] = 1;
-nterm.c_cc[VTIME] = 2;
-nterm.c_lflag &= !ICANON;
-
-ioctl...
-
-My understanding is that a read will return when it recieved VMIN char's
-(one character) or it times out after .2 seconds.
-
-The reads never timed out, though I did get each character typed as
-soon as the key was pressed.
-
-When I changed VMIN to 0, I got the behavior I expected to see, with
-timeouts happenning after .2 seconds.  The read returns 0 for a count
-of characters read if timeout, and 1 if it reads a char.
-
-So, my question is, why didn't I time out when VMIN was > 0?  Should I
-time out, (is this a bug) or should VMIN take precedence over VTIME (an
-error in my comprehension).

If VMIN is not 0, the timeout doesn't begin until after the first char
is in the tty buffer.  This isn't real clear in termio(7) so you might
want to make a note there to remind yourself.
--
Stu Heiss {gargoyle,ihnp4}!jpusa1!stu