シェルが「猫の無駄な使用」を自動的に修正しないのはなぜですか？[閉まっている]

多くの人々は、ラインに沿ってコードを含むonelinersとスクリプトを使用します

cat "$MYFILE" | command1 | command2 > "$OUTPUT"

cat技術的には/usr/bin/cat、コマンドが実行された場合にこれを回避できる新しいプロセス（多くの場合）を開始する必要があるため、最初は「catの無駄な使用」と呼ばれます。

< "$MYFILE" command1 | command2 > "$OUTPUT"

シェルは起動するcommand1だけでstdin、指定されたファイルをポイントするだけです。

シェルがこの変換を自動的に行わないのはなぜですか？「猫の無用な使用」構文は読みやすく、無用な猫を自動的に取り除くのに十分な情報がシェルにあるはずです。catシェルはパスにバイナリを使用する内部代わりに、それを実装することができなければならないので、POSIX規格で定義されています。シェルには、1つの引数バージョンのみの実装と、パス内のバイナリへのフォールバックさえ含めることができます。

2つのコマンドは同等ではありません。エラー処理を検討してください。

cat <file that doesn't exist> | less パイプされたプログラムに渡される空のストリームを生成します...そのようなものとして、何も表示されない状態になります。

< <file that doesn't exist> less バーを開くことに失敗し、その後、まったく開きません。

前者を後者に変更しようとすると、潜在的に空白の入力でプログラムを実行することを期待しているスクリプトをいくつでも壊す可能性があります。

「役に立たないcat」は、スクリプトを実行するときに実際に実行されるものよりも、コードの記述方法に関するものです。これは一種のデザインのアンチパターンであり、おそらくより効率的な方法で実行できることを行う方法です。特定のツールを最適に組み合わせて新しいツールを作成する方法を理解するのは失敗です。パイプラインでいくつsedかのawkコマンドやコマンドをつなげることも、この同じアンチパターンの症状であると言うことができると主張します。

catスクリプト内の「無駄な使用」のインスタンスを修正することは、主にスクリプトのソースコードを手動で修正することです。ShellCheckなどのツールは、明らかなケースを指摘することでこれを支援できます。

$ cat script.sh
#!/bin/sh
cat file | cat

$ shellcheck script.sh

In script.sh line 2:
cat file | cat
    ^-- SC2002: Useless cat. Consider 'cmd < file | ..' or 'cmd file | ..' instead.

これをシェルに自動的に実行させることは、シェルスクリプトの性質上困難です。スクリプトの実行方法は、親プロセスから継承された環境と、使用可能な外部コマンドの特定の実装に依存します。

シェルは必ずしも何catであるかを知っているわけではありません。潜在的には、の任意の場所からのコマンド$PATH、または関数です。

それは、内蔵された場合は、コマンド（それは一部のシェルであってよい）、それはですそれはそのビルトインの意味を知っているだろうとのパイプラインを再編成する能力持っているcatコマンドを使用します。それを行う前に、パイプラインの次のコマンドについて、元のコマンドの後に追加で仮定する必要がありcatます。

標準入力からの読み取りの動作は、パイプに接続されている場合とファイルに接続されている場合では若干異なることに注意してください。パイプはシーク可能でないため、パイプラインの次のコマンドが何をするかに応じて、パイプラインが再配置された場合、異なる動作をする場合としない場合があります（入力がシーク可能かどうかを検出し、そうであるかどうかによって異なることを行う場合がありますそうではありません、いずれにしても、それは異なる振る舞いをするでしょう）。

この質問は（非常に一般的な意味で）「自分で構文エラーを修正しようとするコンパイラはありますか？」（Software Engineering StackExchangeサイトで）ですが、その質問は明らかに無駄なデザインパターンではなく構文エラーに関するものです。 。ただし、意図に基づいてコードを自動的に変更するという考え方はほぼ同じです。

無駄ではないからです。

の場合cat file | cmd、fd 0（stdin）はcmdパイプになり、その場合cmd <file、通常のファイル、デバイスなどになります。

パイプには通常のファイルとは異なるセマンティクスがあり、そのセマンティクスは通常のファイルのセマンティクスのサブセットではありません。

• 通常のファイルは意味のある方法でselect(2)編集またはpoll(2)編集できません。そのselect(2)上で常に「準備完了」を返します。epoll(2)Linuxのような高度なインターフェイスは、通常のファイルでは機能しません。

• Linux上のシステムコール（あるsplice(2)、vmsplice(2)、tee(2)）パイプでのみ作業[1]

以来catあまり使用され、それが組み込まれている余分なプロセスを避けることができますシェルとして実装することができますが、あなたはそのパスで開始したら、同じことは、ほとんどのコマンドで行うことができる-遅く＆clunkierにシェルを変換しますperlまたはpython。代わりに、継続用の使いやすいパイプのような構文を使用して、別のスクリプト言語を記述する方がおそらく良いでしょう;-)

[1]その機会に対応していない簡単な例をご覧になりたい場合は、ここのコメントにいくつかの説明を載せた「exec binary from stdin」git gistをご覧ください。catUUoCなしで動作させるために内部に実装すると、2倍または3倍大きくなります。

役に立たない猫を見つけるのは本当に難しいからです。

私が書いたシェルスクリプトがありました

cat | (somecommand <<!
...
/proc/self/fd/3
...
!) 0<&3

catを介して呼び出されたために削除された場合、実稼働環境でシェルスクリプトは失敗しましたsu -c 'script.sh' someuser。明らかに不必要なcatため、標準入力の所有者が、スクリプトを実行しているユーザーに変更して、/proc作業を介してスクリプトを再度開くようにしました。

tl; dr：コストが予想されるメリットを上回るため、シェルは自動的にそれを行いません。

他の答えは、パイプである標準入力とファイルである標準入力の技術的な違いを指摘しています。それを念頭に置いて、シェルは次のいずれかを実行できます。

1. catファイルとパイプの区別を保持しながら、組み込みとして実装します。これにより、execと、場合によってはforkのコストを節約できます。
2. ファイル/パイプが重要かどうかを確認するために使用されるさまざまなコマンドの知識を使用して、パイプラインの完全な分析を実行し、それに基づいて行動します。

次に、各アプローチのコストと利点を考慮する必要があります。利点は非常に簡単です：

1. いずれの場合も、exec（of cat）を避けてください
2. 2番目のケースでは、リダイレクト置換が可能な場合、フォークを回避します。
3. あなたは、パイプを使用する必要があります場合には、可能性があるフォーク/のvforkを回避することが可能時にはことが、しばしばありません。これは、cat-equivalentを残りのパイプラインと同時に実行する必要があるためです。

したがって、フォークを回避できる場合は特に、CPU時間とメモリを少し節約できます。もちろん、機能を実際に使用する場合にのみ、この時間とメモリを節約できます。そして、あなたは本当にfork / execの時間を節約しているだけです。大きなファイルでは、ほとんどの時間はI / O時間（つまり、猫がディスクからファイルを読み取る時間）です。だからあなたは尋ねる必要があります：catパフォーマンスが実際に重要なシェルスクリプトで（無駄に）どのくらいの頻度で使用されますか？他の一般的なシェルビルトインと比較してください。重要な場所で使用される頻度の10分の1でさえ、（無駄に）使用されるtestとcatは想像しにくいtestです。それは推測です、私は測定していません。これは、実装を試みる前にあなたがやりたいことです。（または同様に、他の誰かに機能要求などで実装するように依頼します。）

次に尋ねる：費用はいくらですか。頭に浮かぶ2つのコストは次のとおりです。（a）シェルにコードを追加すると、サイズが大きくなり（したがってメモリ使用量が増える）、より多くのメンテナンス作業が必要になり、バグなどが発生します。（b）下位互換性の驚き。POSIXではcat、GNU coreutils catなどの多くの機能が省略されているため、cat組み込み関数が何を実装するかを正確に注意する必要があります。

1. 追加のビルトインオプションはおそらくそれほど悪くはありません。既に多くのビルトインが存在する場所にもう1つビルトインを追加します。役立つことを示すプロファイリングデータがあれば、お気に入りのシェルの作成者にそれを追加するよう説得することができます。

2. パイプラインの分析に関しては、シェルが現在このようなことをしているとは思いません（パイプラインの終わりを認識し、分岐を回避できるものもあります）。基本的に、シェルに（プリミティブ）オプティマイザーを追加することになります。オプティマイザーは、多くの場合、複雑なコードであり、多くのバグの原因であることが判明しています。そして、これらのバグは驚くべきものです。シェルスクリプトにわずかな変更を加えると、バグを回避またはトリガーする可能性があります。

追記：猫の無用な使用にも同様の分析を適用できます。利点：読みやすい（ただし、command1が引数としてファイルを取る場合は、おそらくそうではありません）。コスト：追加のforkおよびexec（さらに、command1が引数としてファイルを取ることができる場合、おそらくより混乱したエラーメッセージ）。分析でcatを無駄に使用するように指示された場合は、先に進みます。

このcatコマンドは-、stdinのマーカーとして受け入れることができます。（POSIX、「ファイルが '-'の場合、catユーティリティはシーケンスのその時点で標準入力から読み取るものとします。」）これにより、ファイルまたはstdinの単純な処理が可能になります。

シェル引数$1が次の2つの些細な選択肢を検討してください-。

cat "$1" | nl    # Works completely transparently
nl < "$1"        # Fails with 'bash: -: No such file or directory'

もう1つのcat便利な方法は、単にシェル構文を維持するために意図的にノーオペレーションとして使用される場合です。

file="$1"
reader=cat
[[ $file =~ \.gz$ ]] && reader=zcat
[[ $file =~ \.bz2$ ]] && reader=bzcat
"$reader" "$file"

最後に、UUOCを実際に正しく呼び出すことがcatできるのは、通常のファイル（デバイスまたは名前付きパイプではない）であることがわかっているファイル名で使用され、コマンドにフラグが指定されていない場合だけです。

cat file.txt

他の状況では、catそれ自体の操作が必要になる場合があります。

catコマンドは、シェルが必ずしも実行できない（または少なくとも、簡単に実行できない）ことを実行できます。たとえば、タブ、キャリッジリターン、改行など、通常は表示されない文字を印刷するとします。シェル組み込みコマンドのみでこれを行う方法があるかもしれませんが、頭の上のものは考えられません。GNUバージョンのcatは-A、-v -E -T1 つまたは複数の引数を使用してこれを実行できます（ただし、catの他のバージョンについては知りません）。-nまた、（GNU以外のバージョンでこれができる場合はIDK を使用して）各行の先頭に行番号を付けることもできます。

catのもう1つの利点は、複数のファイルを簡単に読み取ることができることです。そうするには、単にを入力しcat file1 file2 file3ます。シェルで同じことを行うには、注意が必要になりますが、慎重に作成されたループでも同じ結果が得られる可能性があります。そうは言っても、そのような単純な代替案が存在する場合、そのようなループを書くのに本当に時間をかけたいですか？しません！

catはプリコンパイルされたプログラムであるため、catを使用してファイルを読み取ると、おそらくシェルよりもCPUの使用量が少なくなります（明らかな例外は、catが組み込まれたシェルです）。大規模なファイルのグループを読み取ると、これが明らかになる場合がありますが、自分のマシンでこれを行ったことがないため、確信がありません。

catコマンドは、コマンドが強制的に標準入力を受け入れない場合にも役立ちます。以下を考慮してください。

echo 8 | sleep

数字の「8」は、標準入力を受け入れることを意図したものではないため、「sleep」コマンドでは受け入れられません。したがって、sleepはその入力を無視し、引数がないことを訴えて終了します。ただし、次のいずれかを入力した場合：

echo 8 | sleep $(cat)

多くのシェルはこれをsleep 8に拡張し、スリープは終了する前に8秒間待機します。sshでも同様のことができます。

command | ssh 1.2.3.4 'cat >> example-file'

1.2.3.4のアドレスを持つマシン上の「example」ファイルを追加するこのコマンドと「command」から出力されるもの。

そして、それは（おそらく）表面を傷つけているだけです。必要であれば、猫の有用な例をもっと見つけることができると確信していますが、この記事はそれだけで十分です。したがって、これらのシナリオ（および他のいくつかのシナリオ）をすべて予測するようにシェルに要求することは実際には実行可能ではありません。

ユーザーが持っている可能性があることを忘れないでくださいcat、彼には$PATHまさにPOSIXされていないcat（しかし、何かどこかのログを記録でき、おそらくいくつかの変種）。その場合、シェルにそれを削除させたくありません。

PATH 動的に変更し、可能性がありcat ますが、それが信じるものではありません。夢のような最適化を行うシェルを書くのは非常に難しいでしょう。

また、実際にcat は、非常に迅速なプログラムです。それを避ける実用的な理由はほとんどありません（美学を除く）。

FOSDEM2018でのYann Regis-Gianasによる優れたParsing POSIX [s] hellトークもご覧ください。それは、あなたがシェルで夢見ていることをしようとしないようにする他の正当な理由を与えます。

シェルのパフォーマンスが本当に問題である場合、誰かが洗練されたプログラム全体のコンパイラ最適化、静的ソースコード分析、およびジャストインタイムコンパイル技術を使用するシェルを提案したでしょう会議、例：SIGPLAN）。悲しいことに、興味深い研究トピックとしても、現在は研究機関やベンチャーキャピタリストから資金提供を受けていないため、努力するだけの価値がないと推測しています。つまり、シェルを最適化するための重要な市場はおそらくないでしょう。あなたがそのような研究に費やす50万ユーロがあるなら、あなたはそれをする誰かを簡単に見つけるでしょう、そして、それは価値のある結果を与えると信じています。

実用的な面では、パフォーマンスを改善するために、より優れたスクリプト言語（Python、AWK、Guileなど）の小さな（100行未満の）シェルスクリプトを書き換えるのが一般的です。また、（多くのソフトウェアエンジニアリング上の理由から）大きなシェルスクリプトを記述することは合理的ではありません：100行を超えるシェルスクリプトを記述する場合、より読みやすい言語で（読みやすさやメンテナンス上の理由でさえ）書き換えることを考慮する必要があります：プログラミング言語としてのシェルは非常に貧弱です。ただし、多くの大きな生成されたシェルスクリプトがあり、正当な理由（GNU autoconfで生成されたconfigureスクリプトなど）があります。

巨大なテキストファイルに関しては、それらを単一の引数catとして渡すことは良い習慣ではなく、ほとんどのシステム管理者はそれを知っています（シェルスクリプトの実行に1分以上かかると、最適化を検討し始めます）。大きなギガバイトのファイルの場合、それらを処理するのに適したツールではありません。cat

@Kusalanandaの回答（および@alephzeroのコメント）に加えて、catは何でもかまいません。

alias cat='gcc -c'
cat "$MYFILE" | command1 | command2 > "$OUTPUT"

または

echo 'echo 1' > /usr/bin/cat
cat "$MYFILE" | command1 | command2 > "$OUTPUT"

cat（単独）またはシステム上の/ usr / bin / catが実際にcatの連結ツールである理由はありません。

catの2つの「役に立たない」使用法：

sort file.txt | cat header.txt - footer.txt | less

...ここでcatは、ファイルとパイプ入力を混合するために使用されます。

find . -name '*.info' -type f | sh -c 'xargs cat' | sort

...ここでxargsは、事実上無限の数のファイル名を受け入れ、cat必要に応じて何度でも実行できますが、すべて1つのストリームのように動作します。そのため、これは、直接使用xargs sortしない大きなファイルリストに対して機能します。

他のこととは別に、cat-checkはパフォーマンスのオーバーヘッドを追加し、どの使用catが実際に役に立たないかについて混乱を招きcatます。

コマンドが標準ストリームを処理する場合、標準ファイル記述子の読み取り/書き込みのみを考慮する必要があります。コマンドは、stdinがシーク可能/リシーク可能かどうか（パイプまたはファイルを示す）を知ることができます。

どのプロセスが実際にそのstdinコンテンツを提供するかをチェックするミックスに追加する場合、パイプの反対側でプロセスを見つけ、適切な最適化を適用する必要があります。これは、カイルジョーンズによるSuperUserの投稿に示されているように、シェル自体の観点から、また、

(find /proc -type l | xargs ls -l | fgrep 'pipe:[20043922]') 2>/dev/null

リンクされた投稿に示されているように。これは、さらに3つのコマンド（追加fork()のsとexec()s）と再帰的トラバーサル（非常に多くのreaddir()呼び出し）です。

Cとシェルのソースコードに関しては、シェルはすでに子プロセスを知っているので、再帰の必要はありませんが、最適化のタイミングcatと実際に役に立たないタイミングをどのように知ることができますか？実際、catには次のような便利な用途があります。

# adding header and footer to file
( cmd; cat file; cmd ) | cmd
# tr command does not accept files as arguments
cat log1 log2 log3 | tr '[:upper:]' '[:lower:]'

このような最適化をシェルに追加することは、おそらく無駄であり、不必要なオーバーヘッドです。Kusalandaの答えがすでに述べたように、UUOCは、ユーザーがコマンドを組み合わせて最良の結果を得るための最適な方法を理解していないことを重視しています。