Wya*_*ard 226 ls debian coreutils upgrade quoting
我只是注意到,在我的一台机器上(运行 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$
Run Code Online (Sandbox Code Playgroud)
另一个测试,文件名中包含单引号(也回答了 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'
Run Code Online (Sandbox Code Playgroud)
使用新的 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
Run Code Online (Sandbox Code Playgroud)
为什么会这样?我如何正确停止它?
需要明确的是,我自己将 ls 设置为自动彩色输出。它从来没有在事物周围加上引号。
我正在运行bash,coreutils 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
}
Run Code Online (Sandbox Code Playgroud)
Jan*_*lik 145
前言:虽然为这样的答案投票并收工可能会非常令人满意,但请放心,GNU coreutils 维护者并不关心 SO 答案投票,如果您真的想鼓励他们改变,您需要按照这个答案的描述给他们发电子邮件。
2019 年更新:
去年的某个时候,维护人员加倍努力,现在向任何 bug-coreutils@gnu.org 报告有关此问题的报告仅提供样板响应,指向他们网站上的一个令人难以置信的长页面,列出了人们对此更改遇到的问题他们已经承诺无视。
来自 bug-coreutils@gnu.org 报告的持续压力显然产生了影响,迫使生成这个巨大而荒谬的页面,并可能将愿意处理该问题的维护者数量减少到只有一个。
当这么多人认为一个事情是一个错误时,那么无论维护者是否不同意,它都是一个错误。
继续给他们发电子邮件仍然是鼓励改变的最简单方法。
“为什么会这样? ”
几个 coreutils 维护者认为他们比几十年的事实标准更了解。
“我该如何正确阻止它? ”
http://www.gnu.org/software/coreutils/coreutils.html:
错误报告
如果您认为您在 Coreutils 中发现了错误,请尽可能完整地将错误报告发送到<bug-coreutils@gnu.org>,它将自动输入到 Coreutils 错误跟踪器中。在报告错误之前,请阅读常见问题解答。关于如何编写错误报告和提出好的问题的一个非常有用且经常被引用的指南是文档如何以聪明的方式提出问题。您可以浏览以前的帖子并搜索 bug-coreutils 存档。
已经恢复的发行版?这个变化:
发行版不受影响:
“有什么办法不用重新编译就可以解决这个问题? ”
支持者会让你...
通过将 -N 添加到他们的 ls 别名来恢复到旧格式
......在你所有的安装上,在任何地方,在永恒的剩余时间里。
cuo*_*glm 127
您可以选择引用样式:
ls --quoting-style=literal
Run Code Online (Sandbox Code Playgroud)
等同于:
ls -N
Run Code Online (Sandbox Code Playgroud)
或者:
QUOTING_STYLE=literal ls
Run Code Online (Sandbox Code Playgroud)
将其设为别名,或export QUOTING_STYLE=literal在您的设置中设置.bashrc以实现 8.25 之前的行为。
Pád*_*ady 52
关于变化的几点说明。
| 归档时间: |
|
| 查看次数: |
45615 次 |
| 最近记录: |