5 ms·

Control, escape, and meta tricks

129 points by susam 3y ago

dietr1ch 3y ago
Interesting to know, but the very notion of control characters seems very odd to me, there's no typewriter or printer with a bell around anymore. Will we ever get rid of this?
- gumby 3y ago
  It's nice to have in-band signalling in addition to out of band.
- 13of40 3y ago
  Ctrl-G still beeps your console doesn't it?
  - jmholla 3y ago
    It doesn't on mine and I'm not sure why.
    - quesera 3y ago
      Many terminal emulators have a config option to disable audible bell. Some have the option to replace it with a "visual bell".
      - toast0 3y ago
        Some terminal emulators on PCs beep the PC speaker, rather than play a sound through the (high fidelity) audio device. But many PCs no longer have a PC speaker; one way to get a visual bell if the PC speaker output is used, is to connect the power LED to the speaker pins. Makes the power LED a lot more useful too.
        gpderetta 3y ago
        I remember speakerectomy being a thing circa 15-20 year ago, to reliably get rid of the console beep. Most MB still have speaker connections, just have nothing connected to it by default. A couple of years ago I bought a speaker off Amazon (actually a pack of 12 for 1£ as that was the minimum order) just to decode the POST beep when troubleshooting some overclocking issues. Of course I promptly removed it when finished.
        csdvrx 3y ago
        > Of course I promptly removed it when finished. Why? Which issues was it causing if you have the visual bell option in your terminal?
        deleted 3y ago
        [deleted]
      - jmholla 3y ago
        Sadly I checked that and it still doesn't work. I'm using guake on mint.
    - kps 3y ago
      On Linux the terminal is probably using the X11 bell, and many/most distros don't bother to hook that up. On Debian 12 you need to install `libpipewire-0.3-modules-x11` and `systemctl --user restart pipewire.service` for minimal functionality (`xset b` doesn't work).
kps 3y ago
Some of this is not quite right, or right by accident of a particular virtual terminal's features and configuration. Having the Alt/Option modifier send a prefix ESC is usually a terminal configuration option, though often the default. The most common alternative (other than doing nothing) is to set the 8th bit, which was useful in the ISO8859 days but not so much with UTF-8. The vim section of this article depends on the prefix-ESC behaviour, but vim and neovim (and probably other non-ancient editors) will put a capable terminal into modifyOtherKeys mode. In this state the terminal sends a more detailed escape sequence for modifier key combinations, which permits binding combinations that are not distinguishable in the default ‘plain ASCII’ mode. For example, Control-D will send ESC [ 27 ; 5 ; 100 ~ while Control-Shift-D will send ESC [ 27 ; 6 ; 68 ~ (rather than EOT for both) and Alt-D will send ESC [ 27 ; 6 ; 68 ~ rather than ESC D. (Oddly, the author seems to use vim as an editor but emacs editing mode rather than vi editing mode in the shell.) The ‘special case’ control combinations are explained by the https://en.wikipedia.org/wiki/Bit-paired_keyboard https://en.wikipedia.org/wiki/Bit-paired_keyboard where Control does merely flip a bit, originally electromechanically.
- jmholla 3y ago
  > (Oddly, the author seems to use vim as an editor but emacs editing mode rather than vi editing mode in the shell.) I do the same. I gave vim bindings a try in my shell, but I just couldn't get the hang of it. I think vim excels when you are editing multiple lines. And, I can always get to vim to edit the commands if things are getting nuts with Ctrl+X Ctrl+E.
  - mangamadaiyan 3y ago
    Funnily, these days the first thing I do when I start typing at someone else's terminal is "set -o vi". I cannot function effectively without Vi mode in my shell :)
- deleted 3y ago
  [deleted]
- susam 3y ago
  > or right by accident of a particular virtual terminal's features and configuration This is a fair point. Indeed different terminal configurations can produce different results. I have added a little note to my post to clarify this. Thanks for the feedback. > Oddly, the author seems to use vim as an editor I use Emacs. > The ‘special case’ control combinations are explained by the https://en.wikipedia.org/wiki/Bit-paired_keyboard https://en.wikipedia.org/wiki/Bit-paired_keyboard where Control does merely flip a bit, originally electromechanically. I don't think this explains the special cases in a general sense. Firstly, the Wikipedia article discusses shifted keys, not control codes. Secondly, the special cases still need to be explained on a case-by-case basis. It is clear that the control modifier flips a bit but which bit? In case of ctrl+@, ctrl+g, ctrl+h, etc. the 7th LSB is flipped. In case of ctrl+space, the 6th LSB is flipped. A more general rule that covers most of the cases is that the ctrl modifier resets the 6th and 7th LSBs. The exact implementation details, however, vary. As an aside, all of this still leaves how ^? represents DEL in stty and in other contexts requiring printable forms of control characters as a special case. In this case, again, we need to flip the 7th bit. Further, the fact that DEL (decimal 127) is a control character is itself a special case because it is the only control character that has its higher bits (6th and 7th LSBs) set.
svilen_dobrev 3y ago
that's all rather, heavily dependent on lucky combination of at least 2-3 mappings - what 1) X-server/graphical-env converts your keyboard into, then what 2) console/terminal converts that into, and then what 3) app (vim or bash or whatever) running inside terminal, decides to map (and there maybe more layers before, inside, after or instead of these - e.g. hoping 0) kernel transparently passing stuff to 1). e.g. If running without X/graphics, then first is replaced by kernel's keyboard processing ; or if running graphical Vim, then 2+3 are replaced.. (ah, and the dual/multi mode-ness of vim adds extra layer inside it - making say ctrl-U to do undo always isn't that easy) Each of those layers can vary, in different distro's, terminals, versions of same thing, etc. Especialy each and every (X-)terminal-thingie having different idea of how to map (or not) ctrl-F2. Some of them going back to the 197x .. i have tried to make myself a one-mapping-fits-all (say, pressing F2 does ls -alF in terminal+shell, and saves-the-buffer in vim, no matter what/where/when), collecting variants and combinations for last ~25+ years - incl. linux-console and even dos mapping.. and it works mostly.. but still, no silver bullet. see the qini/ folder in https://github.com/svilendobrev/svd_bin https://github.com/svilendobrev/svd_bin everything may be remapped to your liking.. eventually. YMMV. ciao & have fun

129 points by susam 3y ago

Interesting to know, but the very notion of control characters seems very odd to me, there's no typewriter or printer with a bell around anymore. Will we ever get rid of this?

gumby 3y ago
It's nice to have in-band signalling in addition to out of band.
13of40 3y ago
Ctrl-G still beeps your console doesn't it?
- jmholla 3y ago
  It doesn't on mine and I'm not sure why.
  - quesera 3y ago
    Many terminal emulators have a config option to disable audible bell. Some have the option to replace it with a "visual bell".
    - toast0 3y ago
      Some terminal emulators on PCs beep the PC speaker, rather than play a sound through the (high fidelity) audio device. But many PCs no longer have a PC speaker; one way to get a visual bell if the PC speaker output is used, is to connect the power LED to the speaker pins. Makes the power LED a lot more useful too.
      - gpderetta 3y ago
        I remember speakerectomy being a thing circa 15-20 year ago, to reliably get rid of the console beep. Most MB still have speaker connections, just have nothing connected to it by default. A couple of years ago I bought a speaker off Amazon (actually a pack of 12 for 1£ as that was the minimum order) just to decode the POST beep when troubleshooting some overclocking issues. Of course I promptly removed it when finished.
        csdvrx 3y ago
        > Of course I promptly removed it when finished. Why? Which issues was it causing if you have the visual bell option in your terminal?
        deleted 3y ago
        [deleted]
    - jmholla 3y ago
      Sadly I checked that and it still doesn't work. I'm using guake on mint.
  - kps 3y ago
    On Linux the terminal is probably using the X11 bell, and many/most distros don't bother to hook that up. On Debian 12 you need to install `libpipewire-0.3-modules-x11` and `systemctl --user restart pipewire.service` for minimal functionality (`xset b` doesn't work).

kps 3y ago

Some of this is not quite right, or right by accident of a particular virtual terminal's features and configuration. Having the Alt/Option modifier send a prefix ESC is usually a terminal configuration option, though often the default. The most common alternative (other than doing nothing) is to set the 8th bit, which was useful in the ISO8859 days but not so much with UTF-8. The vim section of this article depends on the prefix-ESC behaviour, but vim and neovim (and probably other non-ancient editors) will put a capable terminal into modifyOtherKeys mode. In this state the terminal sends a more detailed escape sequence for modifier key combinations, which permits binding combinations that are not distinguishable in the default ‘plain ASCII’ mode. For example, Control-D will send ESC [ 27 ; 5 ; 100 ~ while Control-Shift-D will send ESC [ 27 ; 6 ; 68 ~ (rather than EOT for both) and Alt-D will send ESC [ 27 ; 6 ; 68 ~ rather than ESC D. (Oddly, the author seems to use vim as an editor but emacs editing mode rather than vi editing mode in the shell.) The ‘special case’ control combinations are explained by the https://en.wikipedia.org/wiki/Bit-paired_keyboard https://en.wikipedia.org/wiki/Bit-paired_keyboard where Control does merely flip a bit, originally electromechanically.

jmholla 3y ago
> (Oddly, the author seems to use vim as an editor but emacs editing mode rather than vi editing mode in the shell.) I do the same. I gave vim bindings a try in my shell, but I just couldn't get the hang of it. I think vim excels when you are editing multiple lines. And, I can always get to vim to edit the commands if things are getting nuts with Ctrl+X Ctrl+E.
- mangamadaiyan 3y ago
  Funnily, these days the first thing I do when I start typing at someone else's terminal is "set -o vi". I cannot function effectively without Vi mode in my shell :)
deleted 3y ago
[deleted]
susam 3y ago
> or right by accident of a particular virtual terminal's features and configuration This is a fair point. Indeed different terminal configurations can produce different results. I have added a little note to my post to clarify this. Thanks for the feedback. > Oddly, the author seems to use vim as an editor I use Emacs. > The ‘special case’ control combinations are explained by the https://en.wikipedia.org/wiki/Bit-paired_keyboard https://en.wikipedia.org/wiki/Bit-paired_keyboard where Control does merely flip a bit, originally electromechanically. I don't think this explains the special cases in a general sense. Firstly, the Wikipedia article discusses shifted keys, not control codes. Secondly, the special cases still need to be explained on a case-by-case basis. It is clear that the control modifier flips a bit but which bit? In case of ctrl+@, ctrl+g, ctrl+h, etc. the 7th LSB is flipped. In case of ctrl+space, the 6th LSB is flipped. A more general rule that covers most of the cases is that the ctrl modifier resets the 6th and 7th LSBs. The exact implementation details, however, vary. As an aside, all of this still leaves how ^? represents DEL in stty and in other contexts requiring printable forms of control characters as a special case. In this case, again, we need to flip the 7th bit. Further, the fact that DEL (decimal 127) is a control character is itself a special case because it is the only control character that has its higher bits (6th and 7th LSBs) set.

svilen_dobrev 3y ago

that's all rather, heavily dependent on lucky combination of at least 2-3 mappings - what 1) X-server/graphical-env converts your keyboard into, then what 2) console/terminal converts that into, and then what 3) app (vim or bash or whatever) running inside terminal, decides to map (and there maybe more layers before, inside, after or instead of these - e.g. hoping 0) kernel transparently passing stuff to 1). e.g. If running without X/graphics, then first is replaced by kernel's keyboard processing ; or if running graphical Vim, then 2+3 are replaced.. (ah, and the dual/multi mode-ness of vim adds extra layer inside it - making say ctrl-U to do undo always isn't that easy) Each of those layers can vary, in different distro's, terminals, versions of same thing, etc. Especialy each and every (X-)terminal-thingie having different idea of how to map (or not) ctrl-F2. Some of them going back to the 197x .. i have tried to make myself a one-mapping-fits-all (say, pressing F2 does ls -alF in terminal+shell, and saves-the-buffer in vim, no matter what/where/when), collecting variants and combinations for last ~25+ years - incl. linux-console and even dos mapping.. and it works mostly.. but still, no silver bullet. see the qini/ folder in https://github.com/svilendobrev/svd_bin https://github.com/svilendobrev/svd_bin everything may be remapped to your liking.. eventually. YMMV. ciao & have fun