> It sounds like you’re talking about output, not input.

Sorry if I misunderstood your question!

However, for inputs the situation is essentially similar: the standards again depend on the terminal, and there can be multiple interpretation than can be conflicting.

Take for example Control-H and Control-? : which is delete and which is backspace depend on the terminal you use!

> I’ve searched several times for such standards before but never had any luck…

There are sources, mostly Thomas E. Dickey (of xterm fame) but personally, I try to take an emulator and make it behave to what my fingers are doing with the minimum level of configuration.

To follow up on Control-H and Control-?, here's what my .inputrc does:

### Delete to the right will be remapped to Delete

"\e[3~": delete-char

# keypad on .

#"\eOn": delete-char

# Special case for VT100 (borks backspace -> make it conditional)

$if term=vt100

"\C-?": delete-char

$endif

### Delete to left will be remapped to Backspace

"\C-?": backward-delete-char

# keypad on 5

#"\eOu": backward-delete-char

# Special case for VT100 (borks backspace -> make it conditional)

$if term=vt100

"\C-H" : backward-delete-char

$endif

(yes, the numpad delete has its own case!)

Here's another one, for Control-Backspace and Control-Delete

### Line cuts will Ctrl-Backspace and Ctrl-Delete

"\C-_": backward-kill-line

"\e[3;5~": kill-line

# Ctrl-Delete variants for tmux and urxvt

"\e[M": kill-line

"\e[3^": kill-line

And last time I checked, Windows terminal needed proper remaps cf https://github.com/microsoft/Terminal/issues/755 like { "keys": "ctrl+backspace", "command": { "action": "sendInput", "input": "\u0017" },

This would piggyback on "\C-h" backward-kill-word - which might be incompatible as it's got a different meaning for VT-100 as noted above.

Quoting you again:

> I’ve searched several times for such standards before but never had any luck…

You shouldn't bother too much about that: terminals are just tools to help you do your work, and while sometimes you can use a lot of pre-existing configurations or documentation to have as much compatibility among the various standards as possible, there are other times when you need to break the standards that stand in your way.

For example, I'm a Windows fan, so I believe Ctrl-C should be copy, Ctrl-V paste, and I don't really care about the traditional unixisms that would cause me try to learn to use Shift-Control-C for copy and Shift-Control-V for paste (just... no!!!)

You may disagree with that, so let's take a more staightfoward example: I care even less of the more obscure unixisms like Ctrl-S/Ctrl-Q that I rarely need. Who needs to "freeze" the tty output in 2022?

So in that case, I've remapped Ctrl-S to "kill word forward", something usually done with Esc-d by default.

To achieve that, in my .bashrc I first clear the defaults with stty:

## Remap ctrl-c to ctrl-x to copy/paste with ctrl-c and ctrl-v, and disable ctrl-s/ctrl-q

stty intr ^X stop undef start undef rprnt undef discard undef swtch undef -ixoff -ixon

# The above doesn't show ^S,^Q,^R and ^O anymore in stty -a

Then I can do the remappings in my .inputrc:

### Backward-kill-word is ctrl-w, while kill-word is alt|esc-d,

# so instead, map ctrl-s which makes ctrl-k|u and ctrl-w|s very close

"\C-s": kill-word

All that to say, standards can be helpful, but there's nothing set in stone: with Control-H and Control-? already causing such headaches (but following all the standards) I don't feel so bad for abusing the standards with my use of Control-S for forward kill word, as it complements nicely the existing Control-K, Control-U and Control-W (all the 3 of which are standard BTW!)