> Codes that are handled by the operating system’s terminal driver, for example when the OS sees a 3 (Ctrl-C), it’ll send a SIGINT signal to the current program

Well, assuming I run my terminal emulator, which itself runs a shell such as bash, in which I ran `ssh`, and now I'm running a long program on a remote host: when I hit `Ctrl-C`, only the long running program on the remote host gets killed.

So what is going on?

Are the shell and ssh ignoring a SIGINT signal and only pass it through?

The original TeleTypes sent ASCII on key press. The control key modifier merely added a bit to the other key pressed. (Except for the Break key.) This has nothing to do with telegraph systems.

TECHNICAL BACKGROUND FOR THE CURIOUS

A modern keyboard sends numbers known as scancodes. These are only roughly standardized. If you have an unusual keyboard you can use the Linux setkeycodes(8) command to remap some scancodes in the tty driver. (The first 88 scancodes cannot be re-mapped.) However, the tty driver is rarely used anymore.

(If you care, the kernel’s tty driver also contains a table called the keymap (see keymaps(5)) that translates scancodes to standard key names called keycodes. For example, left-arrow, lowercase A, or page-up. Software sees keycodes on key-pressed/released events. You can see scancodes and keycodes in a non-GUI console window using showkey(1) command. Many standard keymaps are available for different keyboards (e.g., UK keyboards, German keyboards, etc.) It is the keymap that translates sequences of scancodes into keycodes for the tty driver. Use loadkeys(1) / dumpkeys(1) to change/view the keymap table. (e.g., disable/move caps lock, define function and other extra keys, etc.

The graphics mode (X) uses its own keyboard driver and its own keymap. The X command is xmodmap.

No matter which keyboard driver is used, it translates keycode sequences into Unicode (e.g., ALT+,+c = ç) or some action (e.g., CTL+C sends a signal), determines what strings to send when function keys are pressed, and the effects of modifier (shift, alt, etc.) keys.

On older Linux systems you can see this happen by watching the keyboard lights blink: once when initialized by firmware, once when boot enters text mode, and a third time when X starts. On modern systems (including Windows) the tty driver is skipped so you’ll only see the lights blink twice.

THE BOTTOM LINE

You should ignore all that. The readline(1) library, used by shell, mysql, psql, and lots of other software, allows you to bind keycodes to arbitrary meanings (e.g., symbols, Unicode, shell commands, etc.) with bind or ~/.inputrc. It is readline that provides a history mechanism for these commands, and allows input editing. Low-level control still uses stty (Set the TTY driver). Use this command to affect echo of input, canonical processing of keycodes, etc. Finally, use tput to send ANSI escape sequences to use features such as bold, color, cursor movement, etc. (It is common to use readline’s bind command to bind a key to some tput command.)

I get the feeling we only need 16 or so control characters. We could use those slots for more printable characters instead.

What's that? Doing that would break every single program that uses ASCII? Darn it.

Doing that would open an awesome (terrifying) can of worms.

You start out thinking “no one are using these, surely”. (Outside the terminal and…?)

It’s funny that the lean and mean ASCII is about 25% telegraph junk.

Two of the whitespace characters are useful. And you can use a handful of the rest as metacharacters.