[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[open-cobol-list] Broken function keys with ncurses
From: |
Scott McKellar |
Subject: |
[open-cobol-list] Broken function keys with ncurses |
Date: |
Mon, 15 Dec 2014 14:17:40 -0800 |
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
- [open-cobol-list] Broken function keys with ncurses,
Scott McKellar <=