The C-Kermit versions for UNIX, VMS, and so on, that do not have direct
access to the keyboard and screen, and rely on your console driver, terminal
window, external terminal emulator (such as MS-DOS Kermit), or actual terminal
to perform the terminal functions.
UNIX is an interesting case. Traditionally, UNIX was accessed through a
terminal that was plugged into a terminal port on a timesharing system. Thus,
there is no keyboard and screen -- just a communication port. In
subsequent years, this type of access was largely replaced by terminal servers,
but there was still no keyboard and screen. However, now that we have a
plethora of PC-based UNIX varieties that run on workstations (PCs) that
actually do have a keyboard and screen, it would seem to make sense that
Kermit should be able to see all the keys.
Unfortunately, this is not the case. Most varieties of UNIX do not let the
application see the keyboard. There is no kernel function called "get keyboard
scan code". There is only read(), and read() reads a character, not a
multibyte scan code. Thus, even if your console driver has programmed (say)
your F1 key to send (say) ESC O P, Kermit will read three characters in
succession, as if they were three keystrokes, not one. It has no way of
knowing that you pressed the F1 key. As far Kermit knows, you pressed the Esc
key, then the O key, then the P key.
Now perhaps Linux *does* have a system call to let an application at the
keyboard. But...
So the answer is, for now at least -- and as the documentation states --
C-Kermit's SET KEY command in UNIX (and VMS, AOS/VS, VOS, etc) works only for
keys that generate a single 8-bit value, 0..255. Other types of mappings will
have to be accomplished outside of Kermit by configuring your console driver,
your xterm (e.g. with Xmodmap), and so on.
26 How Do I Use 'SET KEY' with PC F-Keys, etc, in UNIX or VMS
C-Kermit?
Kermit FAQ / Columbia University / kermit@columbia.edu