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

[Simon Sobisch]

Hi Scott,

did you check what's happening if you reconfig your putty session?

See Settings->Terminal->Keyboard->Function Keys and keypad

BTW: I'd suggest to code
      [...]
      DISPLAY 'ENTER "quit" TO EXIT"' LINE 5 END-DISPLAY
       ACCEPT in-fld LINE 2 COL 1
      perform with test after until in-fld = "quit"
          ACCEPT in-fld LINE 2 COL 1
      [...]
or
      [...]
      DISPLAY 'ENTER "quit" TO EXIT"' LINE 5 END-DISPLAY
      perform forever *> quit by EXIT PERFORM below
          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
          IF in-fld = "quit" EXIT PERFORM END-IF
      end-perform
      [...]
you know, just to exit the program as it should ;-)

Simon

 Am 16.12.2014 08:38, schrieb address@hidden:

Date: Mon, 15 Dec 2014 14:17:40 -0800
From: Scott McKellar <address@hidden>
Subject: [open-cobol-list] Broken function keys with ncurses
To: "address@hidden"
	<address@hidden>
Message-ID:
	<address@hidden>
Content-Type: text/plain; charset=us-ascii

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