Why does unicode in a file name cause 'find' to add input to the terminal?

Question

So I have the following file with a strange unicode name. When I do a find command on the file it will print input to the terminal. Look for the 62;c at the bottom of the output. Why does this happen? Is it a bug or intentional? I also got some similar output when I tried tab completion with the file name.

jeff@laptop:/tmp/x$ ls
057. Antonâ??â? n Dvoâ??ôâ??°k - Rusalka - MÆ?õsâ??â? Æ?çku Na Nebi Hlubokâ??©m.mp3
jeff@laptop:/tmp/x$ find
.
./057. Antonâ??â? n Dvoâ??ôâ??°k - Rusalka - MÆ?õsâ??â? Æ?çku Na Nebi Hlubokâ??©m.mp3�©m.mp3
jeff@laptop:/tmp/x$ 62;c

ls -ab shows the following:

057.\ Antonâ\302\210\302\232â\302\211 n\ Dvoâ\302\211\302\210ôâ\302\210\302\232°k\ -\ Rusalka\ -\ MÆ\302\222õsâ\302\210\302\232â\302\211 Æ\302\222çku\ Na\ Nebi\ Hlubokâ\302\210\302\232©m.mp3

One other piece of information. I see the text in a 'terminal', but not in an 'xterm'.

Answer 1

Certain escape sequences query the terminal (or terminal emulator) for certain parameters (such as version, features, current state). These, by design, can only answer by sending the response as an escape sequence as if it was typed by the user.

To try it out, execute e.g.

 echo -ne '\e[c'; sleep 100

and see ^[[?62;c (i.e. an ESC followed by literal [?62;c) appearing, and backspace erasing it while sleep is running, exactly as if you typed this.

An alternate form of this particular escape sequence, using the C1 control code rather than the default C0, which is only supported by some terminal emulators if used in UTF-8, is:

echo -ne '\xC2\x9Bc'; sleep 100

(See the beginning of ctlseqs.html why xterm does not support these.)

Any application emitting such an escape is expected to wait for the response and act on it accordingly. Otherwise they should be careful enough not to produce such output.

For me (Ubuntu 18.04), find recognizes both of these and replaces them with question marks, to make sure they are not sent as-is to the terminal. You might be using an older version of find in an older Ubuntu, which did not yet properly filter these out, or you might be encountering a different escape sequence which is not filtered out (in this latter case we should file a bugreport against findutils). We'd need to know the exact filename (exact sequence of bytes) to continue investigating.

UPDATE: I've just discovered and filed a relevant bug: https://savannah.gnu.org/bugs/?54236. Not sure if you're hitting this one.