不要な猫を気にする必要がありますか？

多くのコマンドラインユーティリティは、パイプまたはファイル名引数から入力を取得できます。長いシェルスクリプトのcat場合、特に最初のコマンドに複数行の引数が必要な場合は、チェーンを開始すると読みやすくなります。

比較する

sed s/bla/blaha/ data \
| grep blah \
| grep -n babla

そして

cat data \
| sed s/bla/blaha/ \
| grep blah \
| grep -n babla

後者の方法は効率が悪いですか？その場合、スクリプトが実行されるかどうか、たとえば1秒間に1回実行されるかどうかを考慮するのに十分な違いはありますか？読みやすさの違いはそれほど大きくありません。

「決定的な」答えは、もちろん無用なcat賞の使用によってもたらされます。

catの目的は、ファイルを連結（または「連結」）することです。ファイルが1つだけの場合、何も連結しないと時間の無駄であり、プロセスにコストがかかります。

コードの読み取りが異なるようにcatをインスタンス化すると、必要のないプロセスと入力/出力ストリームのセットが1つだけ増えます。通常、スクリプトの実際のホールドアップは、非効率的なループと実際の処理になります。ほとんどの最新のシステムでは、1つ余分にcatパフォーマンスを犠牲にすることはありませんが、ほとんどの場合、コードを記述する別の方法があります。

ご指摘のとおり、ほとんどのプログラムは入力ファイルの引数を受け入れることができます。ただし、<STDINストリームが予想される場所であればどこでも使用できるシェルビルトインが常に存在し、既に実行されているシェルプロセスで作業を行うことで1つのプロセスを節約できます。

書いた場所で創造性を発揮することさえできます。通常、次のような出力リダイレクトまたはパイプを指定する前に、コマンドの最後に配置されます。

sed s/blah/blaha/ < data | pipe

しかし、そのようにする必要はありません。それも最初に来ることができます。たとえば、サンプルコードは次のように記述できます。

< data \
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla

スクリプトの読みやすさが懸念事項であり、コードが乱雑であるために行を追加するとわかりやすくなる場合は、コードcatをクリーンアップする他の方法があります。スクリプトを後で簡単に理解できるようにするために私がよく使用するのは、パイプを論理セットに分割して関数に保存することです。スクリプトコードは非常に自然になり、ピップラインのどの部分でもデバッグが容易になります。

function fix_blahs () {
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla
}

fix_blahs < data

その後、続行できfix_blahs < data | fix_frogs | reorder | format_for_sqlます。そのように読み取れるパイプラインは本当に簡単に追跡でき、個々のコンポーネントはそれぞれの機能で簡単にデバッグできます。

以下に、いくつかの欠点の概要を示します。

cat $file | cmd

以上

< $file cmd

• 最初に、注意：$file上記の周りに（意図的に議論の目的で）二重引用符がありません。の場合cat、それは常にを除いて問題ですzsh。リダイレクトの場合、それはbashorの問題でksh88あり、他の一部のシェルでは（スクリプトではなく）インタラクティブな場合のみです。
• 最もよく挙げられる欠点は、余分なプロセスが発生することです。if cmdが組み込みの場合、などの一部のシェルでは2プロセスでさえあることに注意してくださいbash。
• cat組み込みのシェルを除いて、パフォーマンスの面ではまだ実行されています（もちろん、追加のコマンドがロードされ、初期化されています（およびリンクされているライブラリも同様））。
• それでも、性能面では、大きなファイルのために、その手段は、システムが交互にスケジュールする必要がありますcatし、cmdプロセスと常にいっぱいとパイプのバッファを空にします。場合でもcmdない1GB大規模なread()時にシステムコールを、コントロールが間を行き来する必要がありますcatし、cmdパイプは一度に多くのデータの数キロバイト以上保持することはできませんので。
• 一部cmdのs（などwc -c）はcat | cmd、stdinが単なるパイプであるため、stdinが処理できない通常のファイルである場合、いくつかの最適化を実行できます。catパイプを使用するとseek()、ファイル内で使用できないことも意味します。tacまたはtailなどのコマンドの場合、cat入力全体をメモリに保存する必要があるため、パフォーマンスに大きな違いが生じます。
• cat $file、とさえその多くの正しいバージョンは、cat -- "$file"いくつかの特定のファイルのような名前のために正常に動作しません-（あるいは--help始まるか何か-忘れている場合--）を。の使用を主張する場合、信頼性のcatためにcat < "$file" | cmd代わりに使用する必要があります。
• $file読み取り用に開くことができない場合（アクセスが拒否され、存在しません...）、< "$file" cmd一貫したエラーメッセージを（シェルによって）報告し、実行しませんがcmd、cat $file | cmd実行は継続しますcmdが、stdinは空のファイルのように見えます。また< file cmd > file2、のようなものでfile2は、開くfileことができない場合は上書きされません。

<fileパイプラインの終わりに置くことcat fileは、最初に持つことよりも読みにくくなります。自然英語は左から右に読みます。

<fileパイプラインの開始点を置くことは、猫よりも読みにくくなります。単語は、シンボル、特に間違った方向を指しているように見えるシンボルよりも読みやすいです。

を使用catすると、command | command | command形式が保持されます。

ここでの他の答えが直接対処していないように見えることの1つは、catこのように使用しても「作業を行わない無関係な猫プロセスが生成される」という意味で「無駄」ではないということです。「不必要な作業のみを行うcatプロセスが生成される」という意味では役に立ちません。

これら2つの場合：

sed 's/foo/bar/' somefile
<somefile sed 's/foo/bar/'

シェルはsedプロセスを開始し、somefileまたはstdinから（それぞれ）読み取り、処理を行います-改行に達するまで読み取り、その行の最初の「foo」（存在する場合）を「bar」に置き換えてから印刷しますstdoutとループへのその行。

の場合：

cat somefile | sed 's/foo/bar/'

シェルはcatプロセスとsedプロセスを生成し、catのstdoutをsedのstdinにワイヤリングします。catプロセスは、ファイルから数キロバイトまたはメガバイトのチャンクを読み取り、それをその標準出力に書き込みます。そこで、sed sommandは上記の2番目の例のようにそこから取得します。sedがそのチャンクを処理している間、catは別のチャンクを読み取り、次の作業のためにsedの標準出力に書き込みます。

言い換えれば、catコマンドを追加することで必要となる余分な作業は、余分なcatプロセスを生成するだけでなく、ファイルのバイトを1回ではなく2回読み書きする余分な作業でもあります。現在、実質的に言えば、現代のシステムでは、それほど大きな違いはありません。システムが数マイクロ秒の不必要な作業を行う可能性があります。しかし、既にパワー不足のマシンで潜在的にそれを使用している人々に配布することを計画しているスクリプトの場合、多くの反復で数マイクロ秒が加算される可能性があります。