Clever Geek Handbook

Real Unix-実行可能なUnixではない

Unixコマンドラインには驚きがいっぱいです。 たとえば、OSツールで現在のディレクトリにあるファイルのリストを取得するために最もよく使用されるls



ツールは、少なくとも38の異なるフラグを認識することをご存知ですか？



私は知りませんでしたので、この事実を黙らせました 。 そして彼はいくつかの答えを得ましたが、 そのうちの一つは私に不思議に思いました：Unix自体は本当にこれを非難する必要があるのでしょうか？



私の知る限り、LinuxもOS XもUnix哲学に厳密に従って設計されていません。 今日私たちが持っているこれらのUnixデリバティブのみに「Unix」に対する批判を下すのは偽善的です。



しかし、現代のUnixの子孫におけるコマンドラインインターフェイスの問題が、Unix自体のルーツにどの程度まで遡るのかを今でも示しようとしています。 特に、Unixコマンドライン環境は、それぞれが1つの機能を実行するプログラムのエコシステムをサポートできるという考えについて、私の懐疑論を説明しようとします。



しかし、私は少し先を行っています。 これについて説明する前に、 ls



を詳しく見て、何が間違っているのかを正確に把握してみましょう。



たくさんあるが、弱い



ls



異なるバージョンは異なるフラグのセットを認識しますが、一般に、これらのフラグはいくつかの広範なカテゴリに分類できます。 ls



ユーザーはフラグを使用して次のことを行います。





フラグの最初のカテゴリを省略した場合、他の3つには興味深いものがあります。 特に関数型プログラミングの専門家は、身近なものを見ることができます。



つまり、これら3つのカテゴリはそれぞれ、シーケンスで機能する高次の単一の一般関数にほぼ対応しています。





ls



は本当に肥大化しているので肥大化したようです。 多くの高階関数が、フラグの形式でls



に絞り込まれたほとんどの機能を引き受けることができます。



何が悪かったのですか？



各プログラムに自己完結型の機能ユニットを含めるべきだという考えは決して新しいものではありません。 何十年もの間、Unixの支持者はパイプラインの長所を称賛してきました。「プログラム」は、小さな構成可能なフィルターを次々に接続することで、その場で作成されました。 この場合、複雑さを増す方向で、 ls



のような概念的に単純なツールの進化をどのように説明できますか？



Unixコマンドラインの極端なけちは、1つの可能な説明を示唆しています。 Unixが発明されたとき、最大画面幅は約80文字に制限されていました。コンピューターを使用すると、端末の前に座ってキーボードでコマンドを入力することになります。 このような環境では、読みやすさと構成可能性を犠牲にして、より多くの情報を可能な限り少ない文字数に絞ることが理にかなっています。



その時代、最も人気のあるユーティリティの作成者は、可能な限り削減を行う傾向が強くありました。 ls



は、そのフラグが意味のある単語ではなく単一の文字から暗号化されたルーン文字であるという同じ理由でls



と呼ばれます。神が禁じるフレーズ全体：すべてのキーストローク、すべての文字が画面上の実際と表現力豊かな価格を持っていた。



同様に、フラグ自体は、最も一般的な実際のユースケースの略語です。 なぜ時間の90％が隠しファイルを表示したくない場合でも、時間を無駄にし、出力から隠しファイルを除外するフィルタリングステップを追加するのはなぜですか？ ユーザーが名前のみを必要とする時間が90％ある場合に、各ファイルに関するすべての情報を表示するのはなぜですか？



このような考え方-クリックは高価であり、絶対にすべての略語があるべきだということ-は、 ls



とUnixコマンドライン環境全般の多くの問題を特定しています。



「ユニバーサルインターフェイス」



しかし、なぜls



より単純な代替物を書くのではありません-フラグを無視して、任意のディレクトリまたはデフォルトの作業ディレクトリを取り、そこからファイルのリストを返す関数ですか？ 最終的に、Unixのハッキングは他の何よりも簡単ですls



が気に入らない場合は、それを置き換えることができます。



この質問に仮説で答えます。 各関数が厳密に1つの引数（文字列）を取り、厳密に1つの結果（別の文字列）を返すプログラミング言語を想像してください。



ああ、見て-そのような言語が存在し、それはシェルと呼ばれています。



Unixでは、プログラムが互いに通信したり、文字ストリームのみを介してユーザーと通信したりできます。 ファイルのリストを返す関数を作成することはできません。シェルは「リスト」が何であるかを知らず、「ファイル」が何であるかを知らず、「関数」と「プログラム」の違いを知ることができないためです彼の人生は依存します。



プログラムは「引数を受け入れる」ことも「値を返す」こともせず、 stdin



から文字を読み取り、 stdout



文字をstdout



ます。



テキストストリームを処理するプログラムを作成します。これは、ユニバーサルインターフェースであるためです。

ダグラス・マキロイ、「 UNIX環境でのプログラムの設計 」


元のUnixアーキテクトは、テキストストリームの「単純さ」を利点として考えていました。 そのため、プログラム間で転送されるデータに構造を課すことを拒否しました。 不要な複雑さを回避するように設計されたこのソリューションは、代わりに単純に過度の複雑さをさらに下流に転送しました。



ls



フラグの最初のカテゴリ-標準シーケンス変換の省略形に対して発行できなかったフラグを覚えていますか？ これらは、条件付きファイルリストを 、他の特定のプログラム（または場合によっては人間）が解析方法を知っている文字列として非形式的にコーディングするための略語であることがわかります。



システムは、ユーザーが必要とする抽象化を提供できません。 それに応じて、ユーザーはそれらを再発明し 、貧弱で、一貫性がなく、間違った場所で。 これは気のめいるほど一般的な習慣です。



受け入れられないUnix



コンピューターサイエンスの歴史と現在のメンタルモデルが形成された限界を知ることで、一種の超大国が得られます。以前必要だった妥協がばかげて時代遅れになった時期を判断できます。



Don Norman が 1981年のUnixに対する批判で提起したユーザビリティの問題の多くは、現在までほとんど変わっていません。 贈り物として、私たちは「普通のユーザー」をコマンドラインから遠ざけるグラフィカルインターフェースを開発しましたが、「真面目な開発者」は明らかに非人道的な環境に沈んで、そこで意味のある何かを作ると思われます。



使いやすさを改善するためにUnixコマンドラインを再評価する代わりに、最新の機器がインターフェイスを制限しなくなったときに、1970年代半ばの制限を忠実に再現するターミナルエミュレータを作成しました。 新しい代替シェルにshの互換性を要求し、情報を整理するには階層ファイルシステムが最善の方法であると盲目的に信じています 。



40年前にコンピューターとやり取りするための最良のインターフェイスに出会った可能性は何ですか？ 言い換えれば、今日の私たちの行動が理にかなっている可能性は何ですか？



Unixの最も初期のバージョンでさえ、プライベートでしかなく、Unixの哲学の実装が欠けていました。 哲学のより広範な普及を促進したい場合、その欠点を軽視して実装を守るべきではありません。 代わりに、これらの欠点に直接取り組む必要があります。 Unixが構築されている原則の精神（文字ではないにしても）を守りながら、それらを排除するシステムを構築します。


More articles:


All Articles