(僕も含めてw、)コンピュータ界にはオレサマ(「自分の考えが正しい・当たり前」)的な奴が多い・・・

Linux Mint 20に更新した直後に気付いたのだが、lsコマンドの仕様・デフォルトの動作が変わっていた。以下に気付いた(嫌な)点を書く。

  • 空白などを含むファイル名を ' で囲む(クォートする)。
  • -fオプション(元々は「ソートせずに表示する」だった)は-aオプションの機能(. で始まるもの、いわゆる「隠しファイル」も表示する)も含む。
    • 書いたあとで調べたら、FreeBSDやOpenBSDのlsでもこの動作になっていた。だから、僕の記憶違いか、大昔はそうだったけどいつか変わったようだ。
    • 良く考えると、下に書いたソート順の変更(これも誤解かも知れないが・・・)のために、 . で始まるファイルが目立って誤解したのかも知れない。 (→ 調べて解決した。下のソート順の項に書いた。)

それから、-aオプションのソート順も変わった(「隠しファイル」の最初の . を無視している)気がするが、まだOSを更新していない このサーバでも同じだったので、もっと以前からか気のせいか(あるいは、BSD系では僕の記憶どおり(最初に . で始まるファイルがまとまる)なのかも知れない)。

更に調べたら、lsのマニュアルやGNU Coreutilsのマニュアル(2019)のlsの項脚注で謎が解けた。

    • いつからかは不明だが、lsやsortは環境変数LC_ALLまたはLC_COLLATEとLC_CTYPEの設定に従ってソートするようになった。
    • 僕のシステムでは、LC_ALLもLC_COLLATEもLC_CTYPEも設定していないので、LANGかシステムの設定(= "en_US.UTF-8")が参照されて変なソート順になってしまったようだ。 → LC_ALLかLC_COLLATEを"C"や"POSIX"や"ja_JP.UTF-8"にしたら直った。
      • それにしても、USはこんな変なソートを許容しているのだろうか? まあ、USのことはどうでもいいかw
      • ただ不思議なのは、LC_COLLATEが"en_US"(エンコーディング指定なし)なら まともにソートされることだ。ここは謎の領域なのかも知れない。

勝手なクォートはすっっっごく嫌らしい(これ、bashが、頼んでも居ないのにファイル名補完で特殊文字の前に \ を入れるのと同じ考えか)なんか小賢しい。言ってみれば「日本人的なきめ細かさ」wだが、意外にも外国の人がやったのだろうか。以下に実行例を示す(適宜整形した)。

元(ver. 8.25):

$ /bin/ls Music
My Waves Waves

$ /bin/ls -lL Music
total 76
drwxr-xr-x  33 abcde abcde  4096 Nov 12  2019 My Waves
drwxr-xr-x 599 abcde abcde 40960 Oct 21 21:05 Waves

今(ver. 8.30):

$ /bin/ls Music
'My Waves' Waves

$ /bin/ls -lL Music
total 76
drwxr-xr-x  33 abcde abcde  4096 Nov 12  2019 'My Waves'
drwxr-xr-x 599 abcde abcde 40960 Oct 21 21:05  Waves

上はファイルが少ないからまだいいが、多いと ' がちらちらして汚く見にくい。更に小賢しいのは、' はファイル名の前の余白に表示される(だから、最初は本当に、ディスプレイにゴミが付いているのかと思った)ことだ。全く間違っている!

お前はいつからそんな小賢しいやつになっちまったんだ?

と言いたい。

ただ、元の仕様にも問題はあって、上の例の場合、ファイルは"My Waves"と"Waves"なのか"My"と"Waves Waves"なのか すぐには分からない(下に載せているが、これを改善したいというのが変更の一因のようだ)。ただ、普通はもっとファイルが多いので、列の余白の幅で判別できる。

それから、そもそもlsコマンドには(小賢しい)オプションが多過ぎて余りUNIX的でないから、正常進化したとも言えるw だから、これからもどんどん変わっていくのかも知れない。

検索してみると ほとんど出て来ず、意外に文句を言っている人が少ないようだ。ただ、唯一見付かったページによれば2016年には変更されていたようで随分経っているから、みんな慣れてしまって、文句は淘汰されてしまったのかも知れない。

読むと、やっぱり当時は問題になったようで、Debianは ' を付ける変更を戻すパッチ(no_ls_quoting.patch)を出している(それが今はどうなっているかや、パッチ版が手に入るかはまだ調べていない)。変更理由も載っているが、やっぱり小賢しい。以下に引用する。

The reasons we changed the default was:

  • It only happens when outputting to terminals
  • It disambiguates the output for users
  • Output can be pasted back in the shell for further processing
  • Users can get back to the old format by adding -N to their ls alias

最後は盗人猛々しいとか日本の政治家的な感じすらする。普通は新しい動作は新しいオプションにする(この場合、例えば-Nにする)か、デフォルトでoffにする(この場合、環境変数QUOTING_STYLEが設定されていたら、新しい動作にする)だろうが・・・

それに、-fオプションの動作は戻せない(オプションを-Uに変えるしかない)のはどうすればいいのだろう。目で見るならまだいいが、スクリプトで使っている場合、結構大惨事になりそうだが・・・ (上記のように、これは以前からの仕様のようなので取り消した)

例: いわゆる「隠しファイル」(. で始まるファイル・ディレクトリ)を処理対象外にしているスクリプトが、lsの-fオプションに従来の . で始まるものを出さない動作を想定して、ファイル・ディレクトリ一覧を出していたら・・・

それで、"bsdls"のようなコマンドがないか探したがなさそうだったので、仕方ないので(暇だったせいもあるがw)、元のlsの動作に戻す(直す)スクリプトを作り、それをlsのaliasにした。以下に動作を書く。

  • デフォルトではクォートしない。 → -Nオプションを追加する。
    • ただし、環境変数QUOTING_STYLEを"literal"に設定する方が良さそうなので、QUOTING_STYLEが設定されていない場合だけする。
  • -fオプションが指定されていたら-Uに変える。
    • --形式のオプションの単語中にfが含まれることもあるので、それも考慮した。

書いたあとで調べた(上述)結果、実はこのスクリプトは不要で、環境変数QUOTING_STYLEを"literal"に、LC_COLLATEとLC_CTYPEを"C"または"POSIX"(←日本語が化けるので良くない) "ja_JP.UTF-8"に設定すれば大きな問題(違和感)がなくなることが分かった(ただ、それに伴う副作用が出て来るかも知れない)。

まあ、本当に昔のままのlsを使いたいならBSDのを動かした方が良さそうだが、できるのか?

それにしても、ちょっと前からGNUの嫌らしさにも辟易しつつあったが、"GANG is Absolutely Not GNU."※なんて出ないだろうか? もちろん、LinuxはGNUがなければ にっちもさっちも行かないからすぐには無理だろうが。結局、それはBSD系なのか?

※"GNU is Not UNIX"への反抗w

でも、(Linux登場前の大昔は大好きだったものの、)今のBSD系はなんか違うんだよな。コマンドだけならいいかも知れないが、僕には何か合わない。その「何か」は気分とか好みとかで、特に詳しく調べた訳ではないから、どちらの機能・性能がいいとか言っている訳ではない。ただ、BSD系もGNU同様に、彼らの思想で凝り固まっている感じはしている。それが嫌なのかも知れない。

あと、以前の会社の大嫌いなジジイが使っていたのは大きい(爆)

 

PS. 書いたあとで、元々のlsコマンド(BSD版)のマニュアルを探していたら、おもしろい本「オープンソースソフトウェア - 彼らはいかにしてビジネススタンダードになったのか」(1999)のオンライン版が見付かった。いろいろな意味で、そうそうたるメンバーが書いている。付録AのTanenbaumとLinusの論争もおもしろそうだ。

なかなか大変そうなのでw、あとで読もう。

論争は最初の1往復(ここまでしか読んでない)で「勝負あり」って感じだ。僕は(偉そうなジジイに真っ向から反論した)Linusの側だ。

  •   0
  •   0

コメントを書く / Write a comment

名前 / Name    

メール / Mail 

URL