|
From: | Simon Sobisch |
Subject: | Re: [open-cobol-list] Broken function keys with ncurses |
Date: | Tue, 16 Dec 2014 14:26:17 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |