This behaviour is not the same across all shells.
The Bourne Again shell behaves as you describe, displaying the filename in a notation that does not match how such characters are input to the shell. The TENEX C shell does the same. In neither one does the two-character sequence
^C match the one-character filename.
The Almquist and Korn shell just write the control character, which does nothing on many terminals, and include a width of 1, which is thus erroneous, in their column width calculations when displaying the completion list. This throws column alignment off.
The Z shell is the only shell that does something that relates to command input usage. Its menu-based tab completion displays the filename as
$'\003'. That is exactly what one writes with (say) the
rm command, and is exactly what ZLE's tab completion will fill in for the
rm command, to remove the file with the Z shell:
One can match the Korn and Almquist shells.
This is trivial.
-w option simply causes the control character to be output as-is, which again does nothing on many terminals. But at least
ls has the nous to realize that it has a width of 0, and does not get the column alignment calculations wrong.
Yes, this is FreeBSD/TrueOS
And there is no configuration for
ls to match the behaviour of the others.
-b cause an unadorned octal escape sequence to be printed, there being no special C escape sequence for this character. But no shell presents an unadorned octal escape sequence in the completion list. The Z shell comes closest, but uses
$'…' quoting around the octal escape sequence in its completions.
There is nothing at all that matches how the Bourne Again and TENEX C shells display the filename.
Locales are largely irrelevant here. This character is a non-printing control character pretty much irrespective of locale. The C0 range (pace EBCDIC fans) is pretty much universally considered to be control characters.