The Short Answer:
Then, if necessary:
This document applies mainly to versions of Kermit that include true terminal emulators: Kermit 95 for Windows and MS-DOS Kermit for DOS. A section towards the end discusses C-Kermit for UNIX and VMS. Another section contains cautions about application-specific key definitions, and a final section tells where to put key definitions.
Terminal emulation lets you use your PC to make a connection to another computer and interact with it as if your PC were a terminal, even though your PC is not really a terminal and almost certainly does not have the same kind of keyboard as the terminal it is emulating.
One of the most confusing aspects of terminal emulation is making the PC keys do what their keytops say they do. Many people find it quite surprising when the Backspace key doesn't backspace, the Arrow keys don't move the cursor, the Insert key doesn't insert, and so on. In general only the letter and digit keys on the main keypad can be depended upon to act as their labels suggest. The rest, well... each has its own story. This is the story of the Backspace key.
First some terminology. "Backspace" might (or might not) be the name of a key. For example, it is printed on the keytop of the large key at the upper right of main keypad on the PC 101 keyboard. On the DEC keyboard, the same key is labeled with a symbol (<X]) instead of a word. "Backspace" is also is the name of an ASCII control character (ASCII value 8), which might or might not be associated with the Backspace key. "Backspace" is also an abstract concept relating to computers, terminals, and typewriters, having at least two distinct meanings:
To confuse matters even further, your keyboard might have keys other than Backspace that suggest a destructive backspace capability. For example, modern (101-key) PC keyboads include both a "Del" and "Delete" key and one or two Left Arrow keys in addition to the Backspace key. These are strictly for local PC functions and not, in general, for sending characters to the host (but of course in Kermit 95 and MS-DOS Kermit you can map them to do whatever you want).
To cause a destructive backspace operation, the terminal must send an appropriate code to the host, and the host must reply with appropriate terminal-specific codes to move the terminal's cursor and remove the unwanted character. Unfortunately, different hosts and applications use different characters (or sequences) for destructive backspace (and of course, different terminals use different codes for screen formatting). The terminal emulator, Kermit or otherwise, has no way of knowing what host or application you are using, or how it is configured, and therefore no way of knowing what to send when you press the Backspace key.
Of course, Kermit's Backspace key must send something "out of the box", i.e. in the absence of specific instructions from you. This is default backspace assignment. Each emulation (VT100, Wyse 60, Televideo, etc) has an appropriate default assignment, namely what the corresponding key on the real terminal sends.
Therefore, it should be sufficient to tell the host (the computer you are connected to) what your terminal type is, and then it should expect the destructive backspace code that is associated with that terminal. In practice, however, this is rarely enough. In Unix(*), for example, the terminal driver has no connection with the terminal database, so setting or changing your terminal type in Unix has no effect on the characters it uses for destructive backspace (or other forms of editing, such as word and line deletion).
For most emulations Kermit uses one of the two most likely destructive backspace values, and in fact the one that is defined in ASCII to be destructive backspace, in most cases Rubout (RUB), also known as Delete (DEL), character number 127, which sometimes is displayed as "^?". Lest anyone believe this is a frivolous choice, we quote from American National Standard X3.4-1977, Section 5.1, Control Characters:
(Certain other emulations have their own defaults. For example Data General DASHER terminals use Control-Y for character deletion, because that is what Data General operating systems such as AOS/VS expect.)
What happens if the wrong choice is made? If Delete is chosen but is not the host's destructive backspace character, it is likely to:
If Backspace is chosen but is not the host's destructive backspace character, it is likely to:
Even when the host terminal driver uses a specific character such as Backspace for erasure, this does not guarantee that all applications also use it. One well-known case in point is EMACS, which -- in effect -- replaces the terminal driver with its own; in EMACS, control-characters are used as commands: Ctrl-H for Help, Ctrl-B for (cursor) Back, Ctrl-F for (cursor) Forward, etc. If you find EMACS's key definitions disconcerting, you can change them, e.g.:
(define-key global-map "\^h" 'backward-char) ; nondestructive (define-key global-map "\^h" 'backward-delete-char-untabify) ; destructive
The first step in making your Backspace key behave as expected is to choose a terminal emulation in Kermit that is appropriate for the computer you are connecting to, and then (if necessary) tell your host what kind of terminal Kermit is emulating. The command for choosing a terminal emulation in Kermit is:
SET TERMINAL TYPE name
Type a question mark (?) in place of the name to get a list of the available emulations. Here are some examples:
Host Operating System Terminal Type(s) (Open)VMS, RT11, RSX, ... VT100, VT102, VT220, VT320 Digital Unix, Tru64, Ultrix VT100, VT102, VT220, VT320 DECsystem-10, DECSYSTEM-20 VT100, VT102 BBS's ANSI-BBS, AVATAR AOS/VS or DG/UX D210, D215, D217, D463, D470 Stratus VOS TVI950 Linux LINUX (or VT100, VT102, VT220, VT320) SCO XENIX, OSR5, ODT, UNIX SCOANSI Unixware AT386 HP-UX HPTERM, HP2621A AIX AIXTERM, HFT, IBM3151 SINIX SNI-97801, BA80 BeOS BETERM QNX QNX, QANSI Most other UNIX VT100 or VT102 3270 protocol converters VT100, IBM3151, Heath-19
When the most appropriate emulation is not available, most hosts also support VT100 and/or Wyse 50 or 60.
When you make a Telnet, Rlogin, or SSH connection from Kermit to another host, Kermit informs the other host of your terminal type automatically with the messages appropriate to the given protocol. Normally this is sufficient to achieve terminal-type agreement, but will fail if the host uses a different name for your terminal, or does not support it at all. In that case various ruses can be used, most of which are beyond the scope of this document.
When making network connections from Kermit to another host, you can use the SET TELNET TERMINAL-TYPE command to override the terminal-type name sent automatically by Kermit to the Telnet, Rlogin, or SSH server on the remote host. This is handy when the your terminal is known by a different name on the host. A classic example occurs with SCO UNIX hosts, which use a special SCO-specific version of "ANSI" terminal, called SCOANSI by Kermit by ANSI by SCO, which is not the same as the ANSI terminal used elsewhere (e.g. on BBS's), known to Kermit as ANSI. Thus when making a connection from Kermit to an SCO UNIX system, Kermit must be told to:
set terminal type scoansi ; The kind of terminal to emulate set telnet terminal-type ansi ; The name to give to the host
When you make a serial-port or modem connection to a VMS host, as well as to certain other hosts (notably BBS's), the host might send escape sequences designed to provoke responses from the terminal that might indicate its type. These probes, if they are done at all, might fail or worse (they might put your terminal into an unusable state).
For these reasons, it is always best to configure your terminal emulator to emulate a kind of terminal that is known to be supported on the far end of the connection.
When none of the automatic terminal-type identification methods works, you can still tell the host what kind of terminal you have, "manually", by giving a command that depends on the host operating system and, in the case of Unix, also on the shell. Some examples (for the DEC VT100 terminal type):
set terminal /device vt100 (VMS, manual) set terminal /inquire (VMS, automatic) term vt100 (Unix if it has a 'term' command) export TERM=vt100 (Unix ksh or bash) setenv TERM vt100 (Unix csh) TERM=vt100 ; export TERM (Unix sh) TERMINAL VT100 (DEC-20)
If the host does not support the kind of terminal you have, it is often possible to tell it the name of some other kind of terminal that is compatible. For example, suppose you are using C-Kermit on Linux to make a connection to a host that never heard of "Linux" as a terminal type. In this case you can "lie" and say you are using a VT100, because the Linux terminal is a superset of the VT100. Note that terminal-type names in UNIX are case-sensitive; thus the VT100 or VT-100 terminal type usually must be given as "vt100" (lowercase) to match the entry in the host's terminal name list.
After you have successfully informed the host of your terminal type, but the Backspace key still does not work, you have two choices:
Well, sometimes three choices. If the Backspace key sends the DEL character but the host wants the Backspace character, you can type Ctrl-H (hold down the Ctrl key and press the "h" key) instead of using the Backspace key.
Kermit's SET KEY command lets you redefine the Backspace key (or any other key) to send whatever you want it to send (or to take any other actions).
The SET KEY command has two operands: a unique identifier for a key or key combination, called a keycode, and the value or action to be assigned to the key, called the definition:
set key keycode definition
In Kermit commands, a keycode is a number preceded by a backslash. Keycodes are likely to be different for different operating systems, keyboards, and/or Kermit programs. In particular:
Program Keycode for Backspace Key MS-DOS Kermit \270 Kermit 95 \264 C-Kermit \127 (usually!)
(You can find out the keycode of any key or key combination by giving the SHOW KEY command. Kermit prompts you to press a key; you can press any key or key combination and Kermit tells you the keycode.)
As noted above, the characters most commonly used by terminals to send a destructive backspace command to a host computer are single ASCII control characters: Delete and Backspace. Control characters are entered into SET KEY and other Kermit commands by their numeric ASCII value, preceded by backslash (which tells Kermit that these are character codes, rather than literal digits). Here are the characters used for destructive backspace, in decreasing order of likelihood (numbers are shown in decimal):
Character Name Alternative Name ASCII value Delete (DEL) Rubout (RUB) 127 Backspace (BS) Control-H (^H) 8 End of Medium (EM) Control-Y (^Y) 25 Number Sign (#) Pound Sign 35 Cancel Character (CCH) (7-bit) ESC T 27 84 Cancel Character (CCH) (8-bit) 148
(Number sign was used on very old Unix systems that were accessed from Teletype hardcopy terminals; this original Unix default is still found here and there. CCH is an 8-bit (C1) control character from ISO 6429, which has a 7-bit coding as the sequence ESC followed by the letter T.)
Now let's put all this together to show the possible combinations:
Action Kermit 95 MS-DOS Kermit Backspace sends DEL set key \264 \127 set key \270 \127 Backspace sends BS set key \264 \8 set key \270 \8 Backspace sends EM set key \264 \25 set key \270 \25 Backspace sends '#' set key \264 \35 set key \270 \35 Backspace sends CCH set key \264 \148 set key \270 \148 Backspace sends ESC T set key \264 \27T set key \270 \27T
Of course other arrangements are possible too. Remember, you can assign any definition you want to any key or key combination. Some people might prefer to have Backspace always send DEL and (say) Shift-Backspace or Control-Backspace always send Ctrl-H (or vice versa). Example for K95:
set key \264 \127 (Kermit 95: Backspace sends DEL) set key \1151 \8 (Kermit 95: Ctrl-Backspace sends BS)
Where do I put these commands? You can give SET KEY commands at the Kermit prompt, or you can put them in your Kermit customization file: MSCUSTOM.INI for MS-DOS Kermit; K95CUSTOM.INI for Kermit 95.
In Kermit 95, if you use the Dialer to make connections, you can also choose the Backspace-key action for each connection on the Keyboard page of the Dialer notebook for that connection.
In the days of real terminals, there was no way to change what a terminal's Backspace (or equivalent) key sent. Therefore host operating systems such as Unix(*) that did not require a certain kind of terminal for access had to provide a method for adapting to different terminals.
Other host operating systems (such as VMS) always expect the same character for destructive backspace and you can't change it; in the VMS case, you simply have no choice but to configure your emulator to send DEL.
Unix hosts, however, let you change your editing and interruption characters (and much else besides) with the stty command. The particulars of this command vary greatly from one Unix variety to another, so you'll need to view the documentation by typing one of the following commands at the Unix shell prompt:
man stty info stty
Here are a few examples:
Operating System View Settings Change to BS Change to DEL Digital Unix 4.0 stty stty erase ^h stty erase "^?" HP-UX 8.00 stty stty erase ^h stty erase "^?" HP-UX 10.20 stty stty erase ^h stty erase ^? IRIX 6.5 stty -a stty erase ^h stty erase ^? Linux stty -a stty erase ^h stty erase ^? SCO OSR5 stty stty erase "^H" stty erase "^?" SINIX 5.42 stty stty erase "^h" stty erase "^?" Solaris 2.5.1 stty -a stty erase ^h stty erase ^? SunOS 4.1 stty all stty erase ^h stty erase ^? Ultrix 4.3 stty all stty erase ^h stty erase "^?" Unixware 7.0 stty stty erase ^h stty erase ^?
Quoting requirements might vary from shell to shell (sh, ksh, bash, tcsh, etc). When in doubt use doublequotes as shown in many of the examples above. Note that in all cases above, the "^" character is "circumflex" or "caret", normally produced by typing Shift-6. In other words, "^h" in an stty command is circumflex followed by the letter "h", not Control-H itself. Also note that case might be significant in the control-character letter name: "h" or "H".
______________
As noted in the C-Kermit FAQ, and discussed in the platform-specific sections of the C-Kermit Hints and Tips document, C-Kermit (on Unix, VMS, etc) does not have direct access to the keyboard, and can not tell which keys have been pressed to produce the characters that it reads from "standard input". Therefore, there is no way to map keys in C-Kermit.
Nevertheless, C-Kermit includes a SET KEY command similar to that of Kermit 95 and MS-DOS Kermit, but it maps characters, not keys. If your terminal's Backspace key sends a single character, you can have C-Kermit translate it to any other desired character or sequence. To check what your backspace key sends, tell C-Kermit to SHOW KEY, and then press the Backspace key:
C-Kermit> show key Press key: (press Backspace key here) Key code \127 => Character \127 (self, no translation) C-Kermit>
To make it send something else, use SET KEY. In the following example, we make the Backspace key send BS (ASCII 8) and then, in case we actually need to send DEL (ASCII 127) in some situations, we assign it to Ctrl-H:
C-Kermit> set key \127 \8 C-Kermit> set key \8 \127
This sort of thing won't work with function (F) keys, arrow keys, editing keypad keys, and the like, since (in most cases) they are seen by C-Kermit as sequences of characters, and you can't map a sequence. To put it another way, the only keys you can map in C-Kermit are the ones that correspond with ASCII characters: letters, digits, punctuation, and control characters -- CLICK HERE for a complete list -- or with 8-bit single-byte characters (such as A-Umlaut on a German keyboard) if your keyboard has them.
In UNIX, you can map keys outside of Kermit in two situations:
In other situations (as when you are accessing Unix from "outside" via Telnet, SSH, Rlogin, or modem dialup), there is no way for any software on UNIX to know what keys you have pressed. OK, this is an oversimplification: in UNIX, curses-based applications might be able to recognize the escape sequences associated with F- and arrow keys, but (a) this not reliable since the distinction betwwen an escape sequence generated by a key and the same sequence entered separately is uncertain, and (b) even when these sequences are recognized, it is only by curses-based applications, and few, if any, of these provide for any form of mapping.
So many worries over one little key! And we're not done yet. Once you've made the connection and mapped your Backspace key to work as desired when communicating with the remote shell or whatever, you still might find that it doesn't work right in certain applications, particularly full-screen and/or forms-filling ones, such as EMACS (mentioned above), menus, BBS's, or data-entry or query programs. This can happen when the program itself does not use the underlying terminal driver, but reads the user's keystrokes directly. In this case, the application might be hard-coded to use certain characters for certain purposes, regardless of how they are used outside the application.
If the application allows keys to be remapped (in an application-specific manner, of course), as in the EMACS example above, and you can figure out how to do it (for each such application you use), you'll finally have a consistently useful Backspace key. If not, you'll have to learn to cope with the keyboarding requirements of each application.
There are many possiblities:
Consult the documentation for the Kermit program you are using for details.
[ Kermit FAQ ] [ C-Kermit ] [ Kermit 95 ] [ MS-DOS Kermit ] [ Kermit Home ]