PuTTY and FKeys not working

Is this a general question about PuTTY functionality or is it in reference to an application built with one of our COBOL products? If it is COBOL related then please let me know which specific product and version you are using and I will move the question to the correct forum.

Thanks

Chris, ultimately, this is about COBOL, but the underlying problem is just that we can't seem to get Linux to product the exception codes for each function key we are use to seeing in Windows. I'm using PuTTY to access my local Linux (which is virtual) and also to access the customer's Linux network. Same results.

We can run a small script from the command line to see what values the function keys are putting out and most are '000'. I've tried various configurations in PuTTY with no luck.

We have a large RM/COBOL v12.13 application that uses all of the function keys, including Shift Fx and Ctrl Fx. We have a customer that wants to run this application on his Ubantu Linux network. His workstations are all using $TERM=linux. We're including the C=TERMINFO on the runcobol command line but still don't get all of the function keys.

I'm sure there are tons of users running Linux and this should be simple! We're missing something.

In the PuTTY settings for the connection,  what terminal is being emulated?  I am working from memory but I don't remember a 'linux' setting for PuTTY.  Try matching the TERM environment variable to the actual PuTTY setting.  Start with something simple and almost universal such as a VT100 emulation.

I can help more once I am able to work from documentation.

[quote]We can run a small script from the command line to see what values the function keys are putting out and most are '000'.[/quote]

I'm dubious about that. Does your "script" put the tty into raw mode?

Terminal device handling in UNIX-like OSes is quite complicated. You have the terminal emulator (few people use physical terminal devices anymore), the communications protocol, the line discipline (which can include multiple modules in modern UNIX-derived OSes such as Linux), the terminal-type database, and the application (possibly including any of various terminal-handling libraries).

Terminal emulator

Many terminal emulator personalities only include a handful of function keys, or even none at all. The VT100 only had four function keys, so a strict VT100 emulation doesn't support F5 or higher. And how various emulation packages implement personalities varies widely. Only a few terminal types have anything like formal standards, and even those aren't always observed.

The version of PuTTY I'm running (0.66) has a handful of personalities and then several settings that can be tweaked individually. I wouldn't try to guess what they do; I'd run a program that puts the tty in raw mode and then hex-dumps the sequences it gets.

The PuTTY documentation suggests that it passes something for F1 through F12, where that something depends on the configuration.

Communications Protocol

If you're using PuTTY over SSH, this probably isn't a consideration; if memory serves, SSH just provides a clean byte-stream channel.

Telnet, on the other hand, has a host of ways it can interfere with the data stream. Usually this isn't a problem for function-key handling, but the potential is there.

I'm hoping you're not using PuTTY's rlogin support.

Line Discipline

The line discipline is the layer in the tty subsystem between the raw bitstream from the device driver and the Linux (or UNIX) I/O interface. It handles things like converting control characters to signals. Most of what you can do with the stty command affects the line discipline configuration.

There are three main line-discipline operating modes: cooked, cbreak, and raw. To reliably use function keys, typically the tty must be in raw mode, or at least cbreak. It's the responsibility of the application to set the line discipline mode, though that's often done by a library the application calls.

Other line-discipline settings can play havok with interpreting special character sequences, such as those sent by the terminal emulator for function keys. There's really no way to diagnose this problem short of finding out what sequence the emulator is sending, then seeing what the application receives, and trawling through the line-discipline settings if they're different.

Terminal Database

This is your terminfo database (or in some UNIX variants, termcap, though that's mostly superseded). It matches the terminal-type name to a collection of labeled strings that identify how that terminal type identifies various key sequences, or what to send the terminal to achieve various results (cursor positioning and so on). That means:

• The terminal name (which applications and libraries typically take from the value of the TERM environment variable) must identify the correct terminfo entry.
• The terminfo library has to be able to find the terminfo database - this is usually done using the TERMINFO environment variable, if it's set, or a default system location like /usr/share/terminfo.
• That terminfo entry must have information for every key sequence your application wants to use.
• Those key-sequence strings must match what your terminal emulator actually sends (possibly after alteration by communications protocol or line discipline).
• The labels for those key-sequence strings must match the ones queried by your application or the terminal I/O library (such as curses) that it's using. Hopefully this isn't a problem - terminfo is more or less standardized - but sometimes people make mistakes when creating terminfo source files, or they decide to map key sequences differently than the author of the terminal emulation program did.

Just to make things more interesting: Some Micro Focus COBOL products use their own terminfo database, by preference, to work around weaknesses and incompatibilities among terminfos on various UNIX and Linux platforms. I don't know if that applies to RM/COBOL.

Application (and Libraries)

The application, or the terminal I/O library it uses, has to do things correctly too. As I noted above, it will likely have to put the tty into raw mode to get function and other special keys working correctly. And not all terminal I/O libraries recognize all 12 of the function keys, for example.

The application is also responsible for recognizing that a series of bytes represents a single special keypress event. In some cases that's not trivial. (An example is vim, which treats the Esc key specially. Many terminals send function keys as sequences beginning with Esc. So when vim sees an Esc character, it has to try to read ahead for a few more characters to see if it's going to get a special-key sequence, or if it was just a "bare" Esc.)

Any of those could be the issue. Is your PuTTY configured to send the function-key sequences associated with the "linux" terminfo data on your system? Is the tty in raw mode when the application is running? And so on.

We have a large RM/COBOL v12.13 application that uses all of the function keys, including Shift Fx and Ctrl Fx.

That's even more of a problem. I don't know that PuTTY sends different sequences for the function keys with modifiers, and I don't recall standard terminfo labels for modified function keys (though it's been some years since I had to write terminfo files). And even if you get this working with PuTTY it may well not work with other terminal emulators.

[quote user=""Tom"]I am working from memory but I don't remember a 'linux' setting for PuTTY. [/quote]

PuTTY 0.66 settings, Terminal > Keyboard, has a "Linux" option in the radio-button control for "The Function keys and keypad". The docs say that when it's selected, PuTTY will emulate the Linux console's sequences for those keys. So in theory, selecting that option in PuTTY and setting TERM to "linux" ought to match the byte sequences from the emulator to those claimed by terminfo - modulo any interference by the line discipline, and assuming the application applies the correct heuristics for ambiguous sequences, as I noted in my other response.

I don't think it will help with modified function keys (Shift Fn, etc),though. Haven't tested it but I'd be surprised if those are supported through the entire stack.