9A is <a href="https://en.wikipedia.org/wiki/%C5%A0" rel="nofollow">https://en.wikipedia.org/wiki/%C5%A0</a> in CP1252, which is probably what it was meant to be.<p>According to <a href="https://en.wikipedia.org/wiki/C0_and_C1_control_codes" rel="nofollow">https://en.wikipedia.org/wiki/C0_and_C1_control_codes</a> the function of this byte is "To be followed by a single printable character (0x20 through 0x7E) or format effector (0x08 through 0x0D). The intent was to provide a means by which a control function or a graphic character that would be available regardless of which graphic or control sets were in use could be defined. Definitions of what the following byte would invoke was never implemented in an international standard."<p>It's not a VT100 escape code either, so it's a bit odd that it would just cause the termulator to hang.
I can only get this to work in the Gnome terminal with the sequence C2 9A, not with just 9A alone. This is likely related to UTF-8. If your terminal emulator was configured for Latin-1 or something instead of UTF-8 perhaps you wouldn't need the C2 prefix. Note that C2 9A becomes U+009A after UTF-8 decoding.<p>The terminal is actually sending back the sequence "\e[?62;c". The "\e[?" part gets eaten by the line editor and "62;c" shows up as input. Note that despite the claims in the article you <i>are</i> returned to the shell prompt it is just that it has some garbage in the input buffer. You can remove this by backspacing it or you can hit Ctrl+C, etc.<p>A little Googling produces <a href="https://vt100.net/docs/vt220-rm/chapter4.html#S4.17.1" rel="nofollow">https://vt100.net/docs/vt220-rm/chapter4.html#S4.17.1</a> . This feature was designed to let the server interrogate your terminal for the features it supports. The server would send "\e[c" and then it would wait for a response in the form "\e[?...c" where the "..." part indicates the terminal capabilities. And indeed, that does work as expected:<p><pre><code> $ echo -ne '\e[c'; read -r -s -t 1 -n 99; echo -n $REPLY | xxd -g1
00000000: 1b 5b 3f 36 32 3b 63 .[?62;c
</code></pre>
If we look down a little more in that page (<a href="https://vt100.net/docs/vt220-rm/chapter4.html#S4.17.3" rel="nofollow">https://vt100.net/docs/vt220-rm/chapter4.html#S4.17.3</a>) we can see that there is an alternate sequence which also returns this response and it is "\eZ". This is "not recommend[ed]" and it looks like it is actually only supported for backward compatibility with the VT52. That sequence also behaves as expected:<p><pre><code> $ echo -ne '\eZ'; read -r -s -t 1 -n 99; echo -n $REPLY | xxd -g1
00000000: 1b 5b 3f 36 32 3b 63 .[?62;c
</code></pre>
But we're not sending either "\e[c" or "\eZ". Somehow we're getting this answer back in response to "\xC2\x9A" instead. Gnome terminal (and probably the XFCE terminal) uses libvte for its terminal handling. If we look in the source we find this interesting comment:<p><pre><code> /* Escape sequences from \e@ to \e_ have a C1 counterpart
* with the eighth bit set instead of a preceding '\x1b'.
* This is encoded in the current encoding, e.g. in UTF-8
* the C1 CSI (U+009B) becomes \xC2\x9B.
*
* When matching, the bytestream is already decoded to
* Unicode codepoints. In the "code" string, each byte
* is interpreted as a Unicode codepoint (in other words,
* Latin-1 is assumed). So '\x80' .. '\x9F' bytes
* (e.g. the byte '\x9B' for CSI) are the right choice here.
*
* For each sequence containing N occurrences of \e@ to \e_,
* we create 2^N variants, by replacing every subset of them
* with their C1 counterpart.
*/
</code></pre>
I think this is saying that instead of "\e[" (aka "\e\x5B") it will also accept "\x9B" (or "\xC2\x9B" in UTF-8). Which means that "\eZ" (aka "\e\x5A") would have an alias of "\x9A" (or "\xC2\x9A" in UTF-8). So I think that explains how this all happens:<p>- "\xC2\x9A" gets UTF-8 decoded into 9A<p>- 9A gets treated as an alias for "\eZ"<p>- "\eZ" is an old VT52 sequence which causes the terminal to answer back with its capabilities.<p>See also <a href="https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/sci-is-not-decid.html" rel="nofollow">https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/...</a> for how PuTTY used to do the same thing but now no longer does.