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

[Scott McKellar]

I did some further playing around with the putty configuration and got the 
function keys 1 - 4 to work as intended.  Specifically I changed the function 
key/keypad setting from "ESC[n~" to "Xterm R6".

We hadn't used any ncurses-based applications before, so the misconfiguration 
hadn't made a difference until now.  I had tried changing the configuration in 
another context, but the encoding issue was entangled with some issues, and it 
wasn't clear that the putty configuration made a difference.

Thanks also to Kevin Monceaux, who made a similar suggestions.

Scott McKellar


----- Forwarded Message -----
From: Simon Sobisch <address@hidden>
To: Scott McKellar <address@hidden> 
Cc: address@hidden 
Sent: Tuesday, December 16, 2014 7:26 AM
Subject: Re: [open-cobol-list] Broken function keys with ncurses



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