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.

  • I think you're getting confused by the difference between the nonprinting ASCII character Control-C (which is what's in the filename), and "^C", one of many printable representations of that character. Tab completion is going to produce the actual Control-C character, which the shell will represent as "^C" on the command line; but that's not what's actually there, it's a Control-C. Jan 21, 2018 at 21:35
  • @GordonDavisson Thank you for your information. I think the shell is what translates it to ^C (caret followed by a C) just as you said. I admit that I have ignored this. Jan 22, 2018 at 13:10
  • The questioner does not appear confused to me. Xe is asking why there is no configuration of ls (albeit that xe is using the wrong ls for the original question) that does the same thing with a filename containing a control character as the Bourne Again shell does. There is no confusion here. This is indeed the case.
    – JdeBP
    Jan 23, 2018 at 11:22
  • @JdeBP What do you mean by "the wrong ls"? By the way I am male. Jan 23, 2018 at 11:26
  • The original question was on FreeBSD, notice. You aren't using FreeBSD ls.
    – JdeBP
    Jan 23, 2018 at 12:03

1 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 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.

  • Thank you for such an extensive answer, I have learnt a lot from it. Jan 23, 2018 at 13:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .