This question really started from here. I would like to know why different terminals like rxvt and xterm use different values when mapping key combinations? Whilst I am in rxvt or xterm how can I find out the value of a key sequence and easily add this to the .inputrc file?
hysterical historical reasons. Hardware manufacturers didn't always standardize on common single control sequence for the same key, and neither did software writers when glass terminals were replaced by terminal emulators.
You can find out what control sequence a key generates in a particular terminal by typing Ctrl+V then the key (in most shells, or in the input of a command such as
hexdump). Most keys generate a control sequence consisting of the escape character followed by printable characters; the Ctrl+V causes the escape character to be inserted literally.
Fortunately, there are almost no conflicts among the control sequences sent by various terminals. The main exception is that some terminals send
^H for Backspace and
^? for Delete while others send
^? for Backspace and
^[[3~ for Delete. Many terminals have an option to switch between the two backspace/delete modes.
What Gilles said. As for the particular case being referred to, the VT100 and VT220 terminals (which is what today's terminal emulators try to emulate) didn't have keycodes for modifier+arrow key combinations, hence emulators introduced their own.
Not sure exactly why xterm and rxvt have different ones, but perhaps they were introduced independently at the same time. Actually xterm originally used shorter codes than it does today, but those caused problems so were changed eventually.
These days most terminal emulators, in particular the ones for the various desktop environments (including OS X), try to emulate xterm. Rxvt-unicode still carries on the rxvt tradition though.
The keys of interest in
.inputrc are generally control characters, particularly strings beginning with the escape character, usually shown as
^[, but also
How to find the keys sent by your keyboard is well-known: using the
lnext (literal-next) character (usually
^V). Press the
lnext character to suppress interpretation of the next character, and then your special key. This allows the terminal driver to echo the characters in readable form.
Why they differ from one terminal type to another is less well-known.
rxvt are both terminal emulators, nominally based on the same family of hardware terminals from DEC (Digital Equipment). There were many other types of hardware terminals produced during the 1970s and 1980s, but the VT100 and its descendants were among the most popular.
The VT100, it is generally accepted, had no function keys. It had a keypad about the same size as the IBM PC keyboard's numeric keypad. The top row was labeled PF1 through PF4. The usual notion of a function key lies outside that area, in other areas of the keyboard, e.g., a bank of numbered keys at the top or left of the main QWERTY keyboard.
The VT220 extended the VT100 design, adding numbered function keys F6 through F20. It did have F1-F5, but those were used for local functions and generally not usable for programming. The ones that were useful for programming sent escape sequences assigned by DEC. Although there is some standardization of escape sequences sent to a terminal (ECMA-48), there was never a corresponding standard for sequences sent from a terminal. There is only convention, and a sense that special keys which are the "same" as a host-to-terminal function should send the same escape sequence. That especially helped if the terminal were setup in local echo mode.
When xterm was first developed in the later 1980s or early 1990s, someone extended the notion of the VT220's function keys, assigning similar escape sequences to F1-F5. The assignment for keys F21-F24 came later (in 2002), using a similar scheme.
During the mid-1990s, there was no defined scheme in
xterm for modified keys, e.g., using control, shift, etc. Rxvt's developer chose to extend
rxvt using a scheme using different final characters on the strings sent for special keys. This was problematic, since it introduced keys which did not correspond to the host-to-terminal functions, and did not necessarily end with a conventional final character (
$ for example).
xterm, I chose to add numbered keys, using shift and control to extend the numbering range. That worked well enough, but a better scheme was later suggested (patch #94, 1999) by Jeffrey Altman which is implemented in the last series of DEC VTxxx terminals (VT525). That encodes the modifiers as a number, passed along as a parameter to the escape sequence. A few years later (patch #167 in 2002), someone pointed out a problem where those could be confused with other host-to-terminal escapes, and I changed the scheme to avoid that problem.
The developers for Konsole and VTE (GNOME Terminal) copied the scheme used in xterm from 1999, and stayed there, while the terminal description for
xterm was updated. This resulted in a number of bug reports.