[解決済み] 猫の無駄遣い？

前者の理由も重要で、多くの " 良い味 "。 というのは、上記の無言の失敗のように、教育を必要とする人が「でも、あの猫って役に立たないよね」と言った瞬間に思いつかないような、直感的な潜在意識による理由付けに過ぎないのです。

しかし、前者の「センスがいい」という理由も意識してみることにします。その理由は、Unix の直交設計の精神に関係しています。 bar は grep と cut は ls . したがって、少なくとも grep は設計精神に反しています。直交するやり方は grep foo file1 file2 file3 . では cat file1 file2 file3 | grep foo の特殊なケースに過ぎません。 grep foo file1 であり、もしあなたがそれを同じように扱わないのであれば、少なくともあなたは無駄な猫賞を避けようとして脳のクロックサイクルを使っていることになります。

という議論につながります。 grep foo file1 file2 file3 は連結であり grep foo file1 file2 file3 は連結しているので、適切なのは cat が適切ですが cat file1 file2 file3 が連結されていないため cat の両方の精神に違反していることになります。 cat file1 | grep foo と全能のUnixの両方の精神に違反することになります。もしそうなら、Unix は一つのファイルの出力を読んで標準出力に吐き出すために別のコマンドを必要とするでしょう(ページ分割や何かではなく、純粋に標準出力に吐き出すだけです)。つまり、次のような状況になるわけです。 cat または、次のように言います。 cat file1 file2 を避け、意識的に dog file1 を避けながら、賞をもらうために cat file1 のデザインがうまくいけばいいのですから。 dog file1 file2 は複数のファイルが指定された場合、エラーを投げるからです。

うまくいけば、この時点で、ファイルを標準出力に吐き出す個別のコマンドを含めない Unix 設計者に共感していただけると思いますが、同時に dog を他の名前をつけるのではなく concatenate と名づけたことです。 cat の不正確なコメントを削除しました。 <edit> は、実際には < はパイプラインの最初に位置する標準出力にファイルを吐き出すための効率的なノーコピー機能なので、Unixの設計者はこのために特別なものを含めました。 <

次の質問は、単にファイルやいくつかのファイルの連結を標準出力に吐き出すだけで、それ以上の処理を行わないコマンドを持つことがなぜ重要なのでしょうか。1 つの理由は、標準入力で動作するすべての Unix コマンドが、少なくとも 1 つのコマンド ライン ファイルの引数を解析する方法を知っていて、それが存在する場合は入力として使用することを避けるためです。もう一つの理由は、ユーザが以下のことを覚える必要がないようにするためです。(a) ファイル名の引数がどこに行くのか、(b) 前述のサイレント パイプライン バグを回避するためです。

そこで、なぜ </edit> が余分なロジックを持つ理由です。その理由は、頻繁に使用されるコマンドのために、ユーザーの流動性を確保するためです。 スタンドアロン ベースで (パイプラインとしてではなく) 頻繁に使用されるコマンドについて、ユーザーの流動性を確保するためです。これは、使いやすさを大幅に向上させるために、直交性をわずかに妥協したものです。すべてのコマンドがこのように設計されるべきではありませんし、頻繁に使用されないコマンドは、ファイル引数の余分なロジックを完全に避けるべきです（余分なロジックは不必要な脆弱性（バグの可能性）につながることを覚えておいてください）。例外として、ファイル引数を許可する場合は grep . (ちなみに grep はファイル引数を受け入れるだけでなく、かなり必要とする全く別の理由があることに注意してください)

最後に、より良くできたこととして、もし ls (ただし、必ずしも grep ) は、ファイル引数が指定されたときに標準入力も利用可能であれば、エラーを発生させます。