☰

为什么“ls”突然用单引号将空格包裹起来？

tag-icon • tag-icon debian ls quoting upgrade coreutils
为什么“ls”突然用单引号将空格包裹起来？

我刚刚注意到，在我的一台机器（运行 Debian Sid）上，每当我键入ls任何带空格的文件名时，都会用单引号引起来。

我立即检查了我的别名，结果发现它们完好无损。

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ádraig Brady 提供此打印输出：

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

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

为什么会发生这种情况？我该如何正确阻止它？

需要明确的是，我自己将 ls 设置为自动颜色输出。它只是以前从未在事物周围加上引号。

我正在运行bashcoreutils 8.25。

有什么办法可以在不重新编译的情况下解决这个问题吗？

编辑：出现 coreutils 开发人员选择）打破惯例，并使之成为全球默认设置。

更新 - 2017 年 10 月 - Debian Sid 默认重新启用 shell 转义引用。https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877582

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

我以为这已经解决了，但显然它只是被恢复，以便“稳定”的 Debian 分支可以保持其“功能冻结”，同时从新版本中获得其他修复等。所以这是一种耻辱（在我看来）。

更新：2019 年 4 月：刚刚发现PHP 中的虚假错误报告这是由此更改引起的ls。当您让开发人员感到困惑并生成虚假错误报告时，我认为可能是时候重新评估您的更改了。

更新：Android toyboxls现在正在执行与此类似的操作，但使用反斜杠而不是引号。使用 -q 选项使空格呈现为“问号字符”（我没有检查它们是什么，因为它们显然不是空格），因此到目前为止我发现的唯一修复方法是添加将其写入脚本并在启动 shell 时获取它。该函数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
}

答案1

前言：虽然对这样的答案进行投票并结束可能会非常令人满意，但请放心，GNU coreutils 维护者并不关心 SO 答案投票，并且如果你真的想要鼓励他们改变， 你需要给他们发电子邮件正如这个答案所描述的。

2019年更新:
去年的某个时候，维护者加倍努力，现在向任何人提供[电子邮件受保护]关于此问题的报告仅是指向的样板响应他们网站上有一个非常长的页面，列出了人们在这一变化中遇到的问题，而他们却致力于忽略这些问题。
来自源源不断的压力[电子邮件受保护]报告显然产生了影响，迫使生成这个巨大而荒谬的页面，并可能将愿意处理该问题的维护者数量减少到只有一个。
当这么多人认为一个东西是错误时，那么无论维护者是否同意，它都是一个错误。
继续给他们发电子邮件仍然是鼓励变革的最简单方法。

”为什么会发生这种情况？”

一些 coreutils 维护者认为他们比几十年来的事实上的标准更了解。

”我该如何正确阻止它？”

http://www.gnu.org/software/coreutils/coreutils.html:

错误报告

如果您认为您在 Coreutils 中发现了错误，请发送尽可能完整的错误报告至<[电子邮件受保护]>，并且它将自动输入到 Coreutils 错误跟踪器中。在报告错误之前，请阅读常见问题解答。关于如何编写错误报告和提出好问题的非常有用且经常被引用的指南是文档如何以聪明的方式提出问题。您可以浏览以前的帖子并搜索 bug-coreutils 存档。

已经有的发行版恢复了 这个变化：

不受影响的发行版：

  • openSUSE（已使用-N）

”有什么办法可以在不重新编译的情况下解决这个问题吗？”

支持者会让你...

通过将 -N 添加到其 ls 别名来恢复旧格式

...在您的所有安装中，无论在哪里，直到永恒。

答案2

你可以选择引用风格:

ls --quoting-style=literal

与以下相同：

ls -N

或者：

QUOTING_STYLE=literal ls

使其成为别名，或export QUOTING_STYLE=literal在您的中设置.bashrc以实现 8.25 之前的行为。

答案3

关于变化的几点。

  • 它是在 coreutils v8.25 中引入的，并且在 v8.26 中改进了对齐方式
  • 它仅在输出到终端时发生，因此不会破坏脚本
  • 它为用户消除包含空格的文件的输出歧义
  • 它净化输出，所以它是安全的复制并粘贴
  • 输出现在总是有效的复制并粘贴回 shell
  • 用户可以通过在 ls 别名中添加 -N 来恢复旧格式

相关内容