「ls」が突然空白を一重引用符で囲むのはなぜですか？

ls私のコンピュータの1つ（Debian Sidを実行している）でスペースを含むファイル名を入力するたびに、単一引用符で囲むことがわかりました。

すぐに別名を確認しましたが、そのまま残りました。

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を自動カラー出力として直接設定しました。以前は、物事についての引用はありませんでした。

coreutils 8.25を実行していますbash。

再コンパイルせずに解決する方法はありませんか？

編集：coreutils開発者が表示されます。選ぶ）習慣を破ってグローバルデフォルトにします。

---

アップデート - 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

私はこれが修正されたと思いましたが、明らかに「安定した」Debianブランチが新しいリリースで他の修正などをインポートしながら「機能フリーズ」を維持できるように戻ったようです。だから（私の考えでは）恥ずかしいことです。

アップデート：2019年4月：発見したばかりPHPの誤ったエラー報告これはこれらの変更によって引き起こされますls。開発者を混乱させて不正なバグレポートを生成している場合は、変更を再評価する必要があるときだと思います。

アップデート：Android toyboxlsはこれと同様のことを行いますが、引用符の代わりにバックスラッシュを使用します。 -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
}