Ygthkb

While debugging uart on some microcontroller board, I've made a simple firmware that simply responds on every byte received dumping that byte in HEX like "0x**". Then, using different terminal emulators in linux, I've found that there are many different escape encodings for the following keyboard keys:

for F1..F5:

• "33[["+'A'..'E' in linux text console


• "33O"+'P','Q','R','S' (for F1..F4 only) in different gui terminals like mate-terminal and xterm, also running from screen or tmux
  


• "33[11~".."33[15~" in putty (run in windows XP)


• "33[15~" for F5 only in different gui terminals (mate-terminal, xterm), also in screen or tmux
  


• "33[16~" for F5 when using minicom in linux (that seems to recode "33[[E" and "33[15~" into that sequence)

for BACKSPACE:

• 0x08 or 0x7F

for HOME/END:

• "33[1~", "33[4~" in text console, putty and running from screen or tmux
  


• "33O"+'H','F' in mate-terminal
  


• "33[H","33[F" in xterm
  


• "33[1~", "33O"+'F' recoded by minicom from gui terminals

When not explicitly noted, I was using either picocom or socat to interact with /dev/ttyUSB0. Those tools seem not to recode any codes generated by terminal emulator, unlike the minicom.

So the questions are:

• What historic computer systems are inherited in every listed encoding for that keyboard keys?


• What are the historic reasons (if any) for the minicom to change F5 code as well as recode HOME/END?

Partial answer:

General notes: ESC [ is "control sequence introducer", CSI. ESC O is "single-shift-3", SS3.

DEC VT200 terminals sent CSI n~ for function keys F6 onwards, where n = the F-key number plus 11 decimal. F1 to F5 were local only, but it is a reasonable extension to have them send similar sequences with n = 12 to 16. n = 11 to 15 seems like an off-by-one error from this viewpoint.

DEC VT100 terminals sent SS3 P,Q,R,S for four keys labelled PF1 to PF4 on the numeric keypad. Probably VT200 too.

DEC VT100s used CSI 1 to 4 ~ for the so-called editing keypad.

For PC-connected keyboards, of course, the keyboard sends scan codes that are mapped to character sequences by software, so there's plenty of room for latitude here. It is not necessarily true that the PC software was emulating any actual terminal; it just required that the key-mapping software provided something that was potentially useful to application code.

Backspace/delete was a common confusion on terminals of the day. Sometimes a <x]key sent backspace, sometimes it sent delete. Software tended to declare one of those to be the appropriate character-delete operation.

The summary, then, is that many of these came in principle from DEC keyboards, but PC keyboards don't necessarily have the same key layouts, so the terminal emulators do a best-effort (and subjective) job of mapping the keys they need onto the keys they've got.

True terminals used to vary a lot in the code sequences they accepted for their control and code sequences they returned when a key was pressed. And keyboards were less standardized than nowadays, so the keys available used also to vary a lot.

Programs and libraries (the best known is probably curses) which had to interact with several kinds of terminals used a database giving that information. The database is still available here if you really want to find out the origin of the code sequences used by today's terminal emulators.

I won't do that research but just add that they tend to emulate the sequence of popular DEC VTxx series (whose structure has been standardized as ECMA-48 -- there is an equivalent ISO standard, ISO/IEC 6429, but the ECMA one has the advantage of being available for free on the web; one sometimes use "ANSI sequences" either to refer to the ECMA-48 one, or as a more generic way to refer to control sequences), but different models in the series sometimes used different sequences. Terminal emulator also sometimes code sequences having no historical sources for features having little historical precedent.