phil@dgbt.uucp (Phil Blanchfield DGBT/DIP) (03/01/90)
Fellow ULTRIX folk:
I was trying to get a PD package to work with VT100 arrows (function keys)
and I think I discovered a bug in the ULTRIX terminfo/curses stuff.
The included program demonstrates the bug.
Both the ULTRIX an SUNOS man pages for getch() say:
" If keypad is TRUE, and a function key is pressed, the token "
for that function key is returned instead of the raw charac-
ters.
This is also spoken of in "Guide to Curses Screen-Handling".
The included program shows that getch() returns token's only if
you don't "fopen()" a file!!! Actually, the call to fopen here
is never even reached. It works fine on SUNOS both ways.
I am running ULTRIX V3.1 on a VAX-750.
Has anyone else seen this bug?
Does this happen on a RISC?
Is there a work around?
/*
* Test program for terminfo under ULTRIX 3.1
*
* This program demonstrates a bug that I found in the ULTRIX
* terminfo/curses library. With "keypad TRUE", when a function key
* is hit, getch() should return a function key code (int > 401)
* instead of the multi-character string which is actually sent
* by the terminal.
*
* To compile on ULTRIX:
*
* cc prog.c -o prog -lcursesX
*
* To compile on SUNOS:
*
* /usr/5bin/cc prog.c -o prog -lcurses
*
* Notes:
* The only way out is with a control-C and the you will
* have to type: reset without any echo.
*/
#include <stdio.h>
#ifdef sun
#include <curses.h>
#else /* assume ULTRIX */
#include <cursesX.h>
#endif
main()
{
int chr;
char string[30];
FILE *fopen();
initscr();
keypad(stdscr,TRUE);
crmode();
noecho();
for(;;)
{
chr = getch();
sprintf(string,"%d = %o\n",chr,chr);
addstr(string);
refresh();
}
fopen("vtst.c","r"); /* comment out this line and it works!! */
}
--
Phil Blanchfield phil@dgbt.crc.dnd.ca | The Communications Research Centre
UUCP: ...utzoo!lsuc!nrcaer!dgbt!phil | 3701 Carling Avenue, Ottawa CANADApeirce@gumby.cc.wmich.edu (Leonard Peirce) (03/06/90)
In article <1363@dgbt.uucp> phil@dgbt.uucp (Phil Blanchfield DGBT/DIP) writes: >I was trying to get a PD package to work with VT100 arrows (function keys) >and I think I discovered a bug in the ULTRIX terminfo/curses stuff. > [...] >The included program shows that getch() returns token's only if >you don't "fopen()" a file!!! Actually, the call to fopen here >is never even reached. It works fine on SUNOS both ways. > >I am running ULTRIX V3.1 on a VAX-750. This bug has existed since 3.0. I (and others) complained to DEC and they said that it would be fixed in 3.1. They sent me a patch for getch() that works for arrow keys (but not for other stuff like PrevScreen, NextScreen, Select, etc.) so I can't understand why they didn't include it in 3.1. Anyone that wants a copy of the patch can e-mail me. *Maybe* it will be fixed in 4.0. I'm not sure what (if any) connection exists between the problem with getch() and fopen(). From the small example program you included, it looks like fopen() would never get called because it would never break out of the for(;;) loop. -- Leonard Peirce Internet: peirce@gumby.cc.wmich.edu Western Michigan University peirce@gw.wmich.edu Academic Computer Center UUCP: ...!uunet!sharkey!wmichgw!peirce Kalamazoo, MI 49008 Phone: (616) 387-5469
sam@ccsn2.uucp (Sam Moore) (03/06/90)
In article <1363@dgbt.uucp> phil@dgbt.uucp (Phil Blanchfield DGBT/DIP) writes: >Fellow ULTRIX folk: > >I was trying to get a PD package to work with VT100 arrows (function keys) >and I think I discovered a bug in the ULTRIX terminfo/curses stuff. > >The included program demonstrates the bug. > >Both the ULTRIX an SUNOS man pages for getch() say: > >" If keypad is TRUE, and a function key is pressed, the token " > for that function key is returned instead of the raw charac- > ters. > >This is also spoken of in "Guide to Curses Screen-Handling". > >The included program shows that getch() returns token's only if >you don't "fopen()" a file!!! Actually, the call to fopen here >is never even reached. It works fine on SUNOS both ways. > >I am running ULTRIX V3.1 on a VAX-750. > >Has anyone else seen this bug? >Does this happen on a RISC? >Is there a work around? In libcursesX.a there is a function called _fpk() that missuses the select() function. It passes it an int as the 5th parameter rather than a pointer to a struct timeval. It is not RISC related. I don't know of a workaround other than replacing the function in the library. I think DEC knows about this, because there was a posting a few months ago that stated that DEC was not planning a fix. Sam Moore sam@cave.ncsu.edu