Different behavior using tab completion from executing `ls`

Question

I noticed this question on ServerFault:

FreeBSD: Directory called ^C (really!) - how to remove?

I knew about the ^V part long ago. What interests me in that post is that the OP can see the ^C character as ^C(caret followed by a C) in Tab completion, but not in ls. So I look up the man page a bit, and I can find ls -b which outputs \003, ls -N which does not do anything special to ^C, and ls --show-control-chars which shows a Unicode character on the screen.

My first question is, is there a simple way for ls to generate the same type of output as Tab completion, namely ^C(caret followed by a C)? (cat -v behavior).

My second question is, how does $LANG and the $LC_* environmental variables affect the output generated by Tab completion(I think it is documented in complete and maybe the Section 8 in Bash Manual but did not seem to find anything relevant)?

I am using bash 4.3 but solutions for other shells are also welcome.

Answer 1

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:

rm $'\003'

One can match the Korn and Almquist shells.

This is trivial.

The -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 ls.

And there is no configuration for ls to match the behaviour of the others.

Both -B and -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

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.