サブシェルを回避するために何かをすることについて言及しているStack Overflowに関する多くの回答とコメントを見てきました。場合によっては、これには機能的な理由が示されますが (ほとんどの場合、サブシェル内で割り当てられたサブシェルの外部の変数を読み取る必要がある可能性があります)、回避すること自体が目的と見なされる場合もあります。例えば
ではなく
tsv ファイルの 2 つの列の結合である
ため、どちらの方法でもサブシェルがあります。{ ... ; } | ...( ... ) | ...
「目標はサブシェルを回避することだけです」と明示的に述べているファイルをコピーする Linux bash スクリプト
どうしてこれなの？スタイル/エレガンス/美しさのためですか? パフォーマンスのために（フォークを回避するため）？起こりそうなバグを防ぐためですか？他の何か？
いくつかのことが起こっています。
第 1 に、サブシェルのフォークは、1 回だけ発生する場合は気付かないかもしれませんが、ループで実行すると、測定可能なパフォーマンスへの影響が追加されます。パフォーマンスへの影響は、最新の Unixlikes ほどフォークが安価ではない Windows などのプラットフォームでも大きくなります。
第 2 に、サブシェルをフォークすると、複数のコンテキストが存在することになり、それらを切り替えるときに情報が失われます。サブシェルで変数を設定するようにコードを変更すると、サブシェルの終了時にその変数が失われます。したがって、コードにサブシェルが含まれるほど、後でコードを変更するときに注意して、行った状態の変更が実際に永続化されるようにする必要があります。
サブシェルによって引き起こされる驚くべき動作の例については、BashFAQ #24を参照してください。
一般的な考え方としては、特に必要がない限り、余分なシェル プロセスを作成しないことが理にかなっていると思います。
ただし、いずれかを使用できる状況が多すぎて、一方が他方よりも理にかなっていて、一方の方法が他方よりも全体的に優れているとは言えません。純粋に状況に応じたもののように私には思えます。
これがなぜ重要なのかについての私の解釈は次のとおりです。それは答え #2 です。
1 つのサブシェルを回避することについてであっても、パフォーマンスの向上はほとんどありません... Mr Obvious と<insert tool here>呼んcat|grepでsort|uniqくださいcat|sort|uniq。
その概念はUnix の哲学であり、ESR はKISSへの言及によってうまく要約されています: Keep It Simple, Stupid!
私が言いたいのは、スクリプトを書いた場合、それが最終的にどのように使用されるかはわからないということです。そのため、余裕のある小さなバイトまたはサイクルのすべてが重要です。したがって、スクリプトが何十億行もの入力を消費することになる場合、それだけ多くのフォーク/バイト/… より最適化されます。