[open-cobol-list] Broken function keys with ncurses

[Scott McKellar]

How can I correct the behavior of ACCEPT when reading the keyboard via ncurses?


On my own computer at home (Kubuntu 10.4 on amd64, accessed via an xterm 
session), ACCEPT appears to behave as expected, although I haven't tested 
exhaustively.  That is, the value returned in COB-CRT-STATUS agrees with the 
documentation.

However when I run the same test program at work (Red Hat on amd64, accessed 
via putty from Windows 7), some of the keys misbehave.

Here's my test program:


  IDENTIFICATION DIVISION.
  PROGRAM-ID.  cob_fld.

  ENVIRONMENT DIVISION.

  DATA DIVISION.
  WORKING-STORAGE SECTION.

  01  in-fld                pic x(6).
  01  out-fld               pic x(6).

  PROCEDURE DIVISION.

  0000-MAINLINE.

      SET ENVIRONMENT 'COB_SCREEN_EXCEPTIONS' TO 'Y'.
      SET ENVIRONMENT 'COB_SCREEN_ESC'        TO 'Y'.

      DISPLAY 'Hello, Keyboard!' at line 1 column 1.

 *>   Endless loop; terminate with ctrl-C

      perform forever
          ACCEPT in-fld LINE 2 COL 1
          move in-fld to out-fld
          display out-fld at line 3 column 1
          display cob-crt-status at line 4 column 1
      end-perform.

      stop run.


In both environments I compile with "cobc -x cob_fld.cob" using GnuCOBOL 1.1, 
built from source with no special options.  In both environments the value of 
$TERM is "xterm".


On the Red Hat box, most of the keys work as expected, but function keys 1 
through 4 act very strangely.

Suppose I enter "foobar" into the entry field and then press F1.  The program 
displays "foobar" in the output field, as expected, but then replaces the 
contents of the input field with "[11~".   Thereafter it behaves as if I had 
typed those weird characters myself.  The value returned in COB-CRT-STATUS is 
2005, which is supposed to be denote the Escape key (and when I use the Escape 
key, that's the value I get.)

The F2, F3, and F4 keys give similar results, except that the replacement 
strings are "[12~", "[13~", and "[14~", respectively.  The higher-numbered F 
keys work as expected.


I *think* what's happening is that my putty client encodes the F keys as an ESC 
character followed by "[nn~", where "nn" varies with the number of the F key.  
However for some reason the first four aren't recognized properly.  Ncurses 
sees the ESC and treats it as such, and then treats the next four characters as 
literal keypresses.


I know that F1 works as expected in vim, so the putty encoding seems to work in 
that context.  vim uses the termcap database, as I understand it, whereas 
ncurses usually uses terminfo.


So I suspect there's a problem in the terminfo database.  Never having ventured 
into the deep voodoo of terminfo, I don't know how to approach it.  I don't 
even know what the right questions are, nor what to ask of our system 
administrators, who will probably be the ones to fix it.

Any suggestions?

Scott McKellar