为什么“ ls”突然用单引号引起来用空格包装项目？

我只是注意到，在我的其中一台计算机上（运行Debian Sid），只要键入ls，任何带空格的文件名都将单引号引起来。

我立即检查了别名，却发现它们完整无缺。 br />

wyatt@debian630:~/testdir$ ls
'test 1.txt'  test1.txt
wyatt@debian630:~/testdir$ alias
alias ls='ls --color=auto'
alias wget='wget --content-disposition'
wyatt@debian630:~/testdir$

（图片）

另一项测试，文件名称中包含单引号（也回答jimmij的请求）：

wyatt@debian630:~/testdir$ ls
'test 1.txt'  test1.txt  'thishasasinglequotehere'\''.txt'
wyatt@debian630:~/testdir$ touch "'test 1.txt'"
wyatt@debian630:~/testdir$ ls
''\''test 1.txt'\'''  test1.txt
'test 1.txt'          'thishasasinglequotehere'\''.txt'

（图片）

用新的coreutils-8.26输出进行更新（虽然混乱的程度要小得多，但是默认情况下仍然很烦人）。感谢PádraigBrady的此打印输出：

$ ls
"'test 1.txt'"   test1.txt
'test 1.txt'    "thishasasinglequotehere'.txt"

$ ls -N
'test 1.txt'  test1.txt
test 1.txt    thishasasinglequotehere'.txt

为什么会这样？如何正确停止它？

为了澄清，我本人将ls设置为自动彩色输出。

我正在运行bash和coreutils 8.25。

编辑：
似乎出现了coreutils开发人员以为（链接）尽管打破了最低惊讶原则以及UNIX已有46年以上的历史，但还是要使它成为全球默认值是一个好主意。

是否有任何方法无需重新编译即可解决此问题？ >
更新-2017年10月-Debian Sid默认情况下重新启用了外壳转义引用。这太荒谬了。 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877582

在上一个错误报告的回复链的底部，“更改是有意的，并且将会留下来。” https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813164#226

我认为这已解决。

更新：2019年4月：刚刚在PHP中发现了一个伪造的错误报告，该错误报告是由对ls的更改引起的。当您使开发人员感到困惑并生成错误的错误报告时，该重新考虑您的更改了。

更新：Android玩具箱ls现在正在执行类似的操作，但是使用反斜杠代替引号。使用-q选项可使空格呈现为“问号字符”（由于它们显然不是空格，因此我没有检查它们是什么），因此，到目前为止，我发现的唯一解决方法是不添加有问题的设备启动脚本时将其提供给脚本并提供源代码。此功能使ls在终端中使用列，否则每行打印一次，同时由于ls通过管道运行而将其逐个欺骗到打印空间中。

ls() {
    # only way I can stop ls from escaping with backslashes
    if [ -t 1 ]; then
        /system/bin/ls -C $@ |cat
    else
        /system/bin/ls $@ |cat
    fi
}