我在 ServerFault 上注意到这个问题：
^V我很久以前就知道这个部分了。在那篇文章中让我感兴趣的是，OP 可以在制表符补全中将^C字符视为^C（脱字符号后跟C），但在ls.所以我查了一下手册页，我可以找到ls -b哪些输出\003，ls -N哪些对 没有做任何特殊的事情^C，以及ls --show-control-chars哪些在屏幕上显示 Unicode 字符。
我的第一个问题是，是否有一种简单的方法可以ls生成与制表符补全相同类型的输出，即^C（脱字符号后跟C）？ （cat -v行为）。
$LANG我的第二个问题是，环境变量如何$LC_*影响 Tab 补全生成的输出（我认为它记录在completeBash 手册中的第 8 节中，但似乎没有找到任何相关内容）？
我使用的是bash4.3，但也欢迎其他 shell 的解决方案。
答案1
此行为在所有 shell 中都不相同。
Bourne Again shell 的行为如您所描述，以与此类字符输入 shell 的方式不匹配的表示法显示文件名。 TENEX C shell 也做同样的事情。在这两种情况下，两字符序列都不^C与一字符文件名匹配。
Almquist 和 Korn shell 仅写入控制字符，该字符在许多终端上不执行任何操作，并且在显示完成列表时的列宽计算中包含宽度 1，因此这是错误的。这会导致列对齐失效。
Z shell 是唯一执行与命令输入使用相关的操作的 shell。其基于菜单的选项卡补全将文件名显示为$'\003'.这正是人们用（比如说）命令所写的内容rm，并且正是rmZLE 的制表符补全将为命令填充什么，使用 Z shell 删除文件：
rm $'\003'
可以与 Korn 和 Almquist 外壳相匹配。
这是微不足道的。
该-w选项只是导致控制字符按原样输出，这在许多终端上又不执行任何操作。但至少ls有理智认识到它的宽度为0，并且不会导致列对齐计算错误。
是的，这就是 FreeBSD/TrueOS ls。
并且没有配置可以ls匹配其他人的行为。
和-B都会-b导致打印一个未经修饰的八进制转义序列，该字符没有特殊的 C 转义序列。但没有 shell 提供缦完成列表中的八进制转义序列。 Z shell 最接近，但$'…'在其补全中使用八进制转义序列的引用。
没有任何内容与 Bourne Again 和 TENEX C shell 显示文件名的方式相匹配。
区域设置
语言环境在这里基本上无关紧要。该字符是非打印控制字符，几乎与区域设置无关。 C0 系列（EBCDIC 风扇）几乎被普遍认为是控制角色。