It seems to all boil down to the fact that the charset in your locale is ASCII. ASCII is an American charset from the 60s and that is the common denominator for most modern character sets.
That typically happens when locales are not configured (LANG, LC_* environment variables all unset) or when they are set to
That charset defines 128 characters with byte values 0 to 127. All the characters that make up the sh language and found in most command names are in ASCII. But § and ° are not.
Now those symbols are on your keyboard, what should happen when you type it in a terminal emulator?
If you start your terminal emulator in a locale where the charset is ASCII, you're telling your terminal emulator that when you press A, (
XK_a X11 keypress event) it needs to send the encoding of the
a character in the ASCII encoding, that is 0x61. But when you press Shift+§ (
XK_degree X11 keypress event), it should send the encoding for the ° character, but there's no such character in ASCII, so what should it do?
rxvt choose to send the encoding of
° in the iso-8859-1 character set. That's the 8 bit charset of most of the western world (extends ASCII to cover most of the characters used in languages like German, French, British English, Spanish...). Before UTF-8, that was the most commonly used charset.
? for every non-ASCII character.
My gnome-terminal and terminator send the UTF-8 encoding of
bash receives the iso8859-1 encoding of
° (0xb0) like in
xterm, what shall it do?
We've told it the charset was ASCII, so that 0xb0 corresponds to no known character.
In the old days in the US, Ctrl+X was used to enter characters from 0 to 31 (the control characters). In ASCII, that would send the lower 5 bits of the corresponding character. For instance,
0x61, Ctrl+A would send 0x61 & 0x1f, so 0x1 (the
^A, aka C-A character). While Meta+X would send the encoding of
x with the the 8th bit set.
0x61, Meta+A would send 0x61 | 0x80, that is 0xe1. Pressing Meta+0 would send 0x30 | 0x80, that is 0xb0 also known as the M-0 (non-)character.
In ASCII, 0x0 -> 0x1f are used for Control characters for the teletypewriter days, most of which are no longer used, and 0x80 to 0xff is not used, so that was a way to input codes that could be used to do other things than enter text. emacs for instance used those for the editing keys, the
C-B character moves the cursor one character to the left, the
M-B (non-)character moves the cursor one word to the left.
Nowadays, since most people use charsets that extend ASCII by making use of byte values 0x80 to 0xff, those are no longer commonly understood as those meta characters. Meta+X now generally sends two characters instead: the ESC and X characters.
Still, when in a locale where byte values 0x80 to 0xff can't possibly be characters, when
readline) reads a byte value from the tty device like 0xb0, it understands it as being M-0 (which by default is bound to
digit-argument, which explains your
convert-meta setting in the readline configuration. You'll find in the readline documentation (
man 3 readline) that when readline detects that the charset is 7 bit, it sets that to
on to convert those 0xb0 bytes to ESC + 0.
If you turn that off with:
bind 'set convert-meta = off'
output-meta are also
on). Then you'll find that pressing
° gets you a
° displayed. But that would be a 0xb0 iso8859-1 encoding of
° which applications won't know what to do about.
What you need to do is fix the locale to one that has those
° characters. Nowadays, you should only be considering UTF-8 as that covers all characters and is widely supported.
So, check your desktop configuration for your internationalisation setting and choose something like
it_CH.UTF-8 (German/French/Italian speaking Swiss with UTF-8 as the charset) that best match your environment.
You may need to logout and login again for that to be fully taken into account.
Some login managers sometimes allow you to select the locale at login time via some drop-down menu as well.