forとbashの検索

ファイルをループする場合、2つの方法があります。

1. for-loopを使用します。

   for f in *; do
       echo "$f"
   done

2. 使用find：

   find * -prune | while read f; do 
       echo "$f"
   done

これらの2つのループが同じファイルのリストを見つけると仮定すると、パフォーマンスと処理におけるこれら2つのオプションの違いは何ですか？

1。

最初の1つ：

for f in *; do
  echo "$f"
done

と呼ばれるファイル-n、-eおよび-nene一部のbashデプロイメントのようなバリアントでは、バックスラッシュを含むファイル名で失敗します。

二番目：

find * -prune | while read f; do 
  echo "$f"
done

（と呼ばれるファイルにもより多くのケースで失敗した!、-H、-name、(...開始または終了空白と改行文字を含むファイル名）

展開するのはシェルで*、find引数として受け取ったファイルを印刷するだけです。あなたにも使うことができたprintf '%s\n'として、その代わりにprintf組み込みも避けるだろうですあまりにも多くの引数潜在的なエラーを。

2。

の展開*はソートされます。ソートが必要ない場合は、少し速くすることができます。でzsh：

for f (*(oN)) printf '%s\n' $f

または単に：

printf '%s\n' *(oN)

bash私が知る限り、同等のものはないので、に頼る必要がありますfind。

3。

find . ! -name . -prune ! -name '.*' -print0 |
  while IFS= read -rd '' f; do
    printf '%s\n' "$f"
  done

（上記のGNU / BSD -print0非標準拡張を使用）。

それでもfindコマンドを生成して低速while readループを使用するためfor、ファイルのリストが膨大でない限り、ループを使用するよりもおそらく低速になります。

4。

また、シェルワイルドカード拡張とfindは異なりlstat、各ファイルでシステムコールを実行するため、非ソートがそれを補うことはほとんどありません。

GNU / BSD findでは-maxdepth、最適化をトリガーする拡張機能を使用することで回避できますlstat。

find . -maxdepth 1 ! -name '.*' -print0 |
  while IFS= read -rd '' f; do
    printf '%s\n' "$f"
  done

findファイル名が見つかったらすぐに出力を開始するため（stdio出力バッファリングを除く）、ループ内で行うことは時間がかかり、ファイル名のリストがstdioバッファ（4 / 8 kB）。その場合、ループ内の処理は、findすべてのファイルの検索が完了する前に開始されます。GNUおよびFreeBSDシステムでは、stdbufそれをより早く発生させるために使用できます（stdioバッファリングを無効にします）。

5。

各ファイルに対してコマンドを実行するPOSIX / standard / portableの方法findは、-exec述語を使用することです：

find . ! -name . -prune ! -name '.*' -exec some-cmd {} ';'

以下の場合、echoシェルは組み込みのバージョンがありますようにシェルのループを行うよりも効率のですけれども、echoしばらくfind新しいプロセスを生成して実行する必要があります/bin/echoファイルごとにそれに。

複数のコマンドを実行する必要がある場合は、次を実行できます。

find . ! -name . -prune ! -name '.*' -exec cmd1 {} ';' -exec cmd2 {} ';'

ただし、成功したcmd2場合にのみ実行されることに注意してくださいcmd1。

6。

各ファイルに対して複雑なコマンドを実行する標準的な方法は、次を使用してシェルを呼び出すことです-exec ... {} +。

find . ! -name . -prune ! -name '.*' -exec sh -c '
  for f do
    cmd1 "$f"
    cmd2 "$f"
  done' sh {} +

そのとき、組み込みのechoを使用しているためsh、-exec +バージョンがshできるだけ少なく生成されるため、効率的になりました。

7。

では200.000のファイルとディレクトリ上の私のテスト ext4の上の短い名前を持つ、zsh1（パラグラフ2）は最初に簡単なのに続いて、これまで最速であるfor i in *ループ（いつものように、かかわらず、bash多くの低速の他のシェルよりもそのためです）。

2259エントリのディレクトリでこれを試し、timeコマンドを使用しました。

time for f in *; do echo "$f"; done（マイナスファイル！）の出力は次のとおりです。

real    0m0.062s
user    0m0.036s
sys     0m0.012s

time find * -prune | while read f; do echo "$f"; done（マイナスファイル！）の出力は次のとおりです。

real    0m0.131s
user    0m0.056s
sys     0m0.060s

キャッシュミスをなくすために、各コマンドを数回実行しました。これは、出力bashを使用findして（toにbash）パイプするよりも（for i in ...）に保持することをお勧めします

完全を期すfindために、あなたの例では完全に冗長なので、からパイプを落としました。justの出力find * -pruneは次のとおりです。

real    0m0.053s
user    0m0.016s
sys     0m0.024s

また、time echo *（出力は改行で区切られていません、悲しいかな）：

real    0m0.009s
user    0m0.008s
sys     0m0.000s

この時点で、echo *それほど多くの改行を出力していないため、出力がそれほどスクロールしていないので、理由はもっと速いと思います。テストしてみましょう...

time find * -prune | while read f; do echo "$f"; done > /dev/null

収量：

real    0m0.109s
user    0m0.076s
sys     0m0.032s

一方、time find * -prune > /dev/null収量：

real    0m0.027s
user    0m0.008s
sys     0m0.012s

およびtime for f in *; do echo "$f"; done > /dev/null収量：

real    0m0.040s
user    0m0.036s
sys     0m0.004s

そして最後に：time echo * > /dev/nullyields：

real    0m0.011s
user    0m0.012s
sys     0m0.000s

変動の一部はランダムな要因で説明できますが、明らかなようです：

• 出力が遅い
• 配管には少し費用がかかります
• for f in *; do ...はfind * -prune、それ自体ではより遅いですが、パイプを含む上記の構造では、より速くなります。

また、余談ですが、両方のアプローチは、スペースで問題なく名前を処理するように見えます。

編集：

find . -maxdepth 1 > /dev/null対のタイミングfind * -prune > /dev/null：

time find . -maxdepth 1 > /dev/null：

real    0m0.018s
user    0m0.008s
sys     0m0.008s

find * -prune > /dev/null：

real    0m0.031s
user    0m0.020s
sys     0m0.008s

したがって、追加の結論：

• find * -pruneより遅いfind . -maxdepth 1-前者では、シェルはglobを処理してから、の（大きな）コマンドラインを構築していfindます。注意：をfind . -prune返します.。

その他のテスト time find . -maxdepth 1 -exec echo {} \; >/dev/null：：

real    0m3.389s
user    0m0.040s
sys     0m0.412s

結論：

• これまでで最も遅い方法。このアプローチが提案された答えに対するコメントで指摘されたように、各引数はシェルを生成します。

私はあなたの検索をこれに変更しますが、間違いなく検索に行きます：

find . -maxdepth 1 -exec echo {} \;

賢明なパフォーマンスfindは、もちろんあなたのニーズに応じてはるかに高速です。現在使用しforているものは、現在のディレクトリ内のファイル/ディレクトリのみを表示し、ディレクトリの内容は表示しません。findを使用すると、サブディレクトリの内容も表示されます。

findの方が良いと言うのはfor、*最初にファイルを展開する必要があるからです。大量のファイルがあるディレクトリがあると、エラー引数リストが長くなりすぎるのではないかと思います。同じことが言えますfind *

例として、私が現在使用しているシステムの1つには、200万を超えるファイル（それぞれ<100k）のあるディレクトリがいくつかあります。

find *
-bash: /usr/bin/find: Argument list too long

find * -prune | while read f; do 
    echo "$f"
done

無駄な使い方ですfind-あなたが言っているのは、「ディレクトリ（*）内の各ファイルに対して、ファイルを見つけないでください」ということです。また、いくつかの理由で安全ではありません。

• パス内のバックスラッシュは、 -rオプションれreadます。これはforループの問題ではありません。
• パス内の改行は、ループ内の重要な機能を破壊します。これは、の問題ではありませんforループの。

でファイル名を処理するのfindは難しいのでfor、その理由だけで可能な限りループオプションを使用する必要があります。また、find一般的な外部プログラムの実行は、一般的な内部ループコマンドの実行よりも遅くなりますfor。

しかし、私たちはパフォーマンスに関する質問に夢中です！この実験要求は、少なくとも2つの仮定を行っているため、それほど有効ではありません。

A.同じファイルを見つけたと仮定します…

まあ、彼らは最初に同じファイルを見つけるでしょう、なぜなら彼らは同じグロブ、つまり*。しかしfind * -prune | while read f、期待するすべてのファイルを見つけることができない可能性があるいくつかの欠陥に苦しんでいます：

1. POSIX findは、複数のパス引数を受け入れることが保証されていません。ほとんどのfind実装は実行しますが、それでも、それに依存するべきではありません。
2. find *打つと壊れることがありARG_MAXます。for f in *しません、ためARG_MAXに適用されexec、組み込みコマンドではありません。
3. while read f空白で始まるファイル名と空白で終わるファイル名で破損する可能性があります。これwhile readとそのデフォルトのパラメーターを使用してこれを克服することもできREPLYますが、改行を含むファイル名に関してはまだ役に立ちません。

B. echo。ファイルの名前をエコーするためだけにこれを行う人はいません。必要な場合は、次のいずれかを実行してください。

printf '%s\n' *
find . -mindepth 1 -maxdepth 1 # for dotted names, too

whileここのループへのパイプは、ループの終了時に閉じる暗黙のサブシェルを作成します。

質問に答えるために、184個のファイルとディレクトリが含まれる私のディレクトリの結果を以下に示します。

$ time bash -c 'for i in {0..1000}; do find * -prune | while read f; do echo "$f"; done >/dev/null; done'

real    0m7.998s
user    0m5.204s
sys 0m2.996s
$ time bash -c 'for i in {0..1000}; do for f in *; do echo "$f"; done >/dev/null; done'

real    0m2.734s
user    0m2.553s
sys 0m0.181s
$ time bash -c 'for i in {0..1000}; do printf '%s\n' * > /dev/null; done'

real    0m1.468s
user    0m1.401s
sys 0m0.067s

$ time bash -c 'for i in {0..1000}; do find . -mindepth 1 -maxdepth 1 >/dev/null; done '

real    0m1.946s
user    0m0.847s
sys 0m0.933s

find **パスではなく述語のように見えるトークンを生成する場合、正しく機能しません。

--これを修正するために通常の引数を使用することはできません--オプションの終わりを示しており、findのオプションはパスの前にある。

この問題を解決するには、find ./*代わりに使用できます。しかし、それでは、とまったく同じ文字列が生成されませんfor x in *。

find ./* -prune | while read f ..のスキャン機能は実際には使用しないことに注意してくださいfind。./*ディレクトリを実際に走査して名前を生成するのは、グロビング構文です。次に、findプログラムはstat、これらの名前のそれぞれに対して少なくともチェックを実行する必要があります。プログラムを起動してこれらのファイルにアクセスし、I / Oを実行して出力を読み取るオーバーヘッドがあります。

それがどのようになるかを想像するのは難しいですが、より効率的ではありませんfor x in ./* ...。

まあ初心者のためforながら、バッシュに組み込まれ、シェルキーワードでfind別の実行可能ファイルです。

$ type -a for
for is a shell keyword

$ type -a find
find is /usr/bin/find

の forそれが膨張するとループにのみ、それが見つかったディレクトリに再帰的ではないだろう、globstar文字からファイルを検索します。

一方、Findはglobstarによって展開されたリストを与えられますが、この展開されたリストの下にあるすべてのファイルとディレクトリを再帰的に検索し、それぞれをパイプして whileループにます。

これらのアプローチは両方とも、スペースを含むパスまたはファイル名を処理しないという意味で危険と見なされる場合があります。

これで、これらの2つのアプローチについてコメントする価値があると思います。

findによって返されたすべてのファイルを単一のコマンドで処理できる場合（上記のエコーの例には明らかに当てはまらない）、xargsを使用できます。

find * |xargs some-command

何年もの間私はこれを使用しています：

find . -name 'filename'|xargs grep 'pattern'|more

画面からスクロールしないようにgrepが検索してパイプすることができるパターンを含む特定のファイル（* .txtなど）を検索します。時々>>パイプを使用して、後で確認できる別のファイルに結果を書き込みます。

結果のサンプルは次のとおりです。

./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:Message-ID: <A165CE5C-61C5-4794-8651-66F5678ABCBF@usit.net>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:In-Reply-To: <A165CE5C-61C5-4794-8651-66F5678ABCBF@usit.net>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:  <A165CE5C-61C5-4794-8651-66F5678ABCBF@usit.net>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:  <A165CE5C-61C5-4794-8651-66F5678ABCBF@usit.net>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:Message-ID: <448E53556A3F442ABC58203D6281923E@hypermax>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2011-April.txt:URL: http://mylist.net/private/rodgersorganusers/attachments/20110420/3f