私のマシン(Debian Sidを実行している)の1つで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á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の開発者が ((link)) を破ったにもかかわらずグローバルなデフォルトを作成することは良い考えだと思われます 最小の驚きの原則 と46年以上UNIXの伝統。
再コンパイルせずにこれを修正する方法はありますか?
更新-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月:ls
へのこの変更によって引き起こされた PHPの偽のバグレポート が見つかりました。開発者を混乱させ、誤ったバグレポートを生成しているときは、変更を再考するときです。
更新:Android toybox ls
はこれと同様のことをしていますが、引用符の代わりにバックスラッシュを使用しています。-qオプションを使用すると、スペースが「クエスチョンマーク文字」としてレンダリングされます(それらが何であるかは確認されません。それらは明らかにスペースではないため)、問題のデバイスをルート化せずにこれまでに見つけた唯一の修正は、これをスクリプトに追加し、シェルを起動するときにソースを取得することです。この関数はls
は、ターミナルの場合は列を使用し、それ以外の場合は1行に1つずつ出力しますが、パイプを介して実行されるため、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
}
引用スタイル を選択できます:
ls --quoting-style=literal
と同じ:
ls -N
または:
QUOTING_STYLE=literal ls
エイリアスにするか、export QUOTING_STYLE=literal
に.bashrc
を設定して8.25より前の動作を実現します。
変更に関するいくつかのポイント。