Scroll to navigation

FIND(1) General Commands Manual FIND(1)

名前

find - ディレクトリ階層をたどって、条件を満たすファイルを検索する

書式

find [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point...] [expression]

説明

このマニュアルページは GNU 版 find の使用法を説明している。 GNU 版 find は、指定された探索開始点 (訳注: 探索の始点となるパス。上記書式の starting-point...) 以下のディレクトリツリーを一つづつ探索し、与えられた式 (訳注: 上記書式の expression) を、優先規則に従いつつ (「演算子」セクションを参照)、 左から右へ評価することによって検索を行う。 式の結果が確定すると (たとえば、and 演算で左辺が偽になった場合や、or 演算で左辺が真になった場合など)、 find は処理の対象を次のファイル名に移す。 探索開始点が指定されていない場合は、`.' が指定されたものと見なされる。

もし find を使用しているのが、セキュリティの問題をおろそかにできない環境なら (たとえば、 find を使って探索しているディレクトリが、自分以外のユーザにも書き込み可能な場合など)、 findutils 関連文書の 「Security Considerations」の章をお読みになるとよい。 Finding Files という文書で、findutils に同梱されているはずだ (訳注: info "Finding Files" で読むことができる)。 その文書では、他の点についてもこのマニュアルページよりはるかに詳しい説明や考察が行われているので、 この文書以上に情報源としてお役に立つことだろう。

オプション

-H, -L, -P というオプションは、シンボリックリンクをどう処理するかを決める。 こうしたオプションに続くコマンドライン引き数は、探索対象となるファイル名やディレクトリ名と見なされる。 ただし、それは、`-' で始まる引き数や、`(' とか `!' という引き数が、続いて現れるまでだ。 そうした引き数、及びそれに続くいかなる引き数も、何を捜すべきかを記述した式であると解釈される。 探索開始点のパスが一つも指定されていない場合は、カレントディレクトリ以下が探索の対象になる。 また、式が一つも指定されていない場合は、-print が式として使用される (もっとも、いかなる場合でも、-print の代わりに -print0 の使用を考えた方が多分よいだろうが)。

このマニュアルページで説明する「オプション」には、式の一部として使われるものもある。 そうしたオプションは、find の動作を制御するものであり、指定する位置は、探索開始点の最後のパス名のすぐ後になる。 それに対して、-H, -L, -P, -D, -O という五つの「本来」のオプションは、指定するなら、最初のパス名の前で指定しなければならない。 なお、ダッシュを二個重ねた -- を使用して、後に続く引き数はオプションではないと明示することも可能だ (それでも、探索開始点となるパス名のリストでワイルドカードを使用するならば、 始点のすべてが `./' か `/' で始まるようにしておいた方が、たいてい無難である)。

シンボリックリンクをまったくたどらない。これがデフォルトの動作である。find がファイルの情報を調べたり表示したりする際に、そのファイルがシンボリックリンクだったら、 そのシンボリックリンクそのもののプロパティから取得した情報が使用されることになる。

シンボリックリンクをたどる。find がファイルの情報を調べたり表示したりする際に、 リンク先のファイルのプロパティから取得した情報が使用されることになり、 リンクそのものの情報は利用されない (ただし、シンボリックリンクがリンク切れしていたり、 find がリンク先のファイルを調べることができなかった場合は除く)。 このオプションを使用すると、自動的に -noleaf が指定される。 後で -P オプションを指定し直しても、-noleaf は依然として有効なままである。 -L が有効になっているとき、find が探索中にサブディレクトリを指すシンボリックリンクに出会うと、 そのシンボリックリンクが参照しているサブディレクトリが探索される。
-L オプションが有効だと、述語 -type は (訳注: 「述語 (predicate)」とは、式を構成する基本要素、すなわち、オプション、検査、 アクションのこと)、シンボリックリンクそのものに対してではなく、 常にシンボリックリンクが指しているファイルのタイプに対してマッチを行うようになる (シンボリックリンクがリンク切れしている場合を除く)。 find の実行中にシンボリックリンクがリンク切れになるようなアクションを行うと (たとえば、-delete を使うと)、動作がわけのわからないものになるかもしれない。 -L を使用すると、述語 -lname や -ilname は常に偽を返す。

コマンドライン上で指定された引き数を処理するとき以外、シンボリックリンクをたどらない。 すなわち、原則として、 find がファイルの情報を調べたり表示したりする際に、 シンボリックリンクそのもののプロパティから取得した情報が使用されることになる。 ただし、この動作には例外が一つあり、それは、コマンドラインで指定されたファイルがシンボリックリンクであり、そのリンクが解決できる場合だ。 その場合は、リンク先が何であれ、そこから取得した情報が使用され (つまり、リンクがたどられる)、シンボリックリンク自体の情報は、リンク先のファイルを調べることができなかったときの、控えの情報として使用される。 なお、-H が有効なとき、コマンドラインで指定されたパスの中に (訳注: つまり探索開始点の中に) ディレクトリへのシンボリックリンクがあった場合も、そのディレクトリの中身が調べられることになる (もっとも、-maxdepth 0 を指定すれば、 当然ながら、この動作は抑制されることになるだろうが)。

一つ以上の -H, -L, -P を指定した場合は、後のものが前のものを上書きする。 従って、コマンドラインで最後に指定されたものが、効果を持つわけだ。 -P はデフォルトなので、-H や -L を指定しないかぎり、-P オプションが有効になっていると考えるべきである。

GNU find は実際の探索に取りかかる前にコマンドラインの処理を行うが、 その際 stat システムコールを使ってファイルの情報を調べることがよくある。 上述のオプションは、そのとき引き数がどう処理されるかにも影響を与える。 具体的に説明しよう。いくつかの検査では、コマンドラインで指定したファイルを目下検査の対象になっているファイルと照合する。 いづれの検査でも、コマンドラインで指定したファイルは、情報が調べられた後、そのプロパティのいくつかが保存されることになる。 名前を指定したファイルが実際にはシンボリックリンクであるとき、-P オプションが有効な場合は (すなわち、 -H と -L のどちらのオプションも指定されていない場合は)、 照合に使用される情報は、シンボリックリンクのプロパティから取得したものである。 それ以外の場合、使用されるのはリンク先のファイルのプロパティから取得した情報だ。 ただし、find が (たとえば、権限が不十分だとか、リンク先のファイルが存在しないとかの理由で) リンクをたどれない場合は、リンクそのもののプロパティが使われることになる。

-H や -L オプションが有効な場合は、 -newer の引き数として指定されたのがシンボリックリンクなら、 その参照がたどられて、リンク先のファイルからタイムスタンプが取得されることになる。 同じことが、 -newerXY, -anewer, -cnewer についても言える。

式の一部として使用される -follow オプションには -L と同様の効果があるが、 それが現れた位置から有効になるという点が異なる (すなわち、-L が使われずに、-follow が使われた場合、 -follow より後で指定されたいかなるシンボリックリンクも参照がたどられるが、 その前に指定されたシンボリックリンクは参照がたどられない)。

-D debugoptions
診断用の情報を出力する。find が期待どおりに動いてくれないとき、 問題の原因追求に役立つことがある。デバッグオプションを複数指定するときは、コンマで区切る。 findutils のバージョンの間で、デバッグオプションの互換性は保証されていない。 有効な全デバッグオプションのリストについては、find -D help の出力を見るとよい。 有効なデバッグオプションの中には、以下のものがある。
デバッグ用オプションを説明する。
式の構造 (expression tree) をオリジナルな形と最適化した形で示す。
stat や lstat システムコールを使ってファイルを調べたとき、メッセージを表示する。 find プログラムは、そうしたシステムコールの回数を最少にしようとする。
式の構造 (expression tree) の最適化に関する診断情報を表示する。-O オプションを参照。
各述語が何回成功し、何回失敗したかを示す情報を要約して表示する。
問い合わせの最適化を有効にする。find プログラムは、全体的な効果を維持しつつ、検査の順序を並べ替えることによって、実行速度を上げる。 すなわち、付加的な作用のある述語同士については、相互の相対的な順序を変更しないということだ。 各最適化レベルで行われる最適化は、以下のとおりである。
0
最適化レベル 1 と同じである。
1
これはデフォルトの最適化レベルであり、伝統的な動作に当たる。 式を並べ替えるとき、ファイル名にのみ基づいた検査 (たとえば、 -name や -regex) が先に実行されるようにする。
2
検査 -type や -xtype の実行は、ファイル名のみに基づいたいかなる検査よりも後になるが、 inode から情報を取得する必要があるどんな検査よりも先になる。 最近の Unix には readdir() 関数でファイルタイプを取得できるものが多いので、 こうした述語は、stat 関数でファイルの情報を取得するところから始めなければならない述語よりも、評価に時間がかからないのである。 なお、-fstype FOO という述語を使った場合に、 find の起動時に既知になっていない (すなわち、`/etc/mtab' に存在しない) ファイルシステムのタイプ FOO を指定すると、-fstype FOO は -false と同じことになる。
3
この最適化レベルでは、コストに基づいた問い合わせの最適化を徹底して行う機能が有効になる。 検査の順序が必要なら変更され、コストのかからない (すなわち、速い) 検査が先に行われて、よりコストのかかる検査が後回しにされる。 コストがほぼ同じ場合には、その述語が真を返しそうか、偽を返しそうかによって、評価の順番が変わってくる。 or 演算では、真を返しそうな述語が先に評価され、and 演算では、偽になりそうな述語が先に評価されるのである。
コストに基づいた最適化機能は、ある検査が真を返す確率について一定の考えを持っている。 場合によっては、その確率について、問題のテストの特性が考慮されることもある (たとえば、 -type f は、 -type c よりも、真になる可能性が高いと見なされる)。 コストに基づいた最適化機能は、現在のところその効果を評価中である。 もし、それによって find の性能が実際に向上することがなければ、捨てられることになるだろう。 反対に、信頼性があり、問題を起こしにくく、効果的であることがはっきりした最適化は、 そのうち下位の最適化レベルでも採用されるかもしれない。とは言え、リリース 4.3.x のシリーズでは、 デフォルトの動作 (すなわち、最適化レベル 1) を変更する予定はない。 なお、findutils のソースに付属するテスト集は、そのテストのすべてを各最適化レベルの find で実行して、どの最適化レベルでも結果が同じになることを保証している。

式 (EXPRESSION)

コマンドライン上で探索開始点 (starting-point) のリストの後ろに続く部分は、「式 (expression)」である。 式は、言わば問い合わせの細目のようなものであり、 どういうファイルがマッチするのかと、そのマッチしたファイルをどう処理するのかを記述している。 式は一連の要素からなっている (訳注: このマニュアルでは、そうした式の要素、 特にオプション、検査、アクションをまとめて「述語 (predicate)」と呼んでいる)。

検査 (Tests)
検査は、通常、考慮の対象になっているファイルの何らかのプロパティ (property、属性、性状) に基づいて、真または偽の値を返す。たとえば、-empty という検査は、対象になっているファイルが空の場合にのみ、真になる。

[訳注]:
バージョン 4.4.2 までの翻訳では、この Tests を「判別式」と訳してきたが、今回は素直に「検査」と訳すことにした。同じものである。
アクション (Actions)
アクションには付加的な作用があり (たとえば、標準出力に何かを表示するなど)、 通常、その作用の実行に成功したか失敗したかに基づいて、真または偽を返す。 たとえば、-print というアクションは、対象になっているファイルの名前を標準出力に表示する。

グローバルオプション (Global options)
グローバルオプションは、検査やアクションがコマンドライン中のどこで指定されていても、 その動作に影響を与える。また、グローバルオプションは、常に真を返す。 たとえば、-depth オプションを指定すると、find は、ファイルシステムをたどるとき、 深い方から先に (depth-first order) 処理していくことになる (訳注: 下記の -depth の説明を参照)。

位置オプション (Positional options)
位置オプションが影響を与えるのは、それより後に続く検査やアクションに対してだけである。 また、位置オプションは常に真を返す。たとえば、-regextype オプションは、その位置が意味を持ち、 コマンドライン上でそれより後に現れる正規表現に対して、正規表現のどの方言かを指定することになる。

演算子 (Operators)
演算子は、式を構成する事項同士を結びつけるものである。 演算子には、-o (論理 OR を意味する) や -a (論理 AND を意味する) などがある。 演算子がないところには、-a があるものと見なされる。

式の中に -prune や -print 以外のアクションがまったく存在しない場合は、 式全体の結果が真になったすべてのファイルに対して -print が実行される。

-delete というアクションはオプションのようにも働く (自動的に -depth を有効にするからである)。

位置オプション

位置オプションは、常に真を返す。 位置オプションが影響を与えるのは、コマンドライン上でそれより後に現れる検査に対してだけである。

-amin, -atime, -cmin, -ctime, -mmin, -mtime において、今日 (すなわち 0 日前) の始まりを今現在から 24 時間前ではなく、コマンド実行当日の 0 時にする。 このオプションが影響を及ぼすのは、コマンドラインで自分より後に指定された検査に対してだけである。

[訳注]:
-amin, -cmin, -mmin のことも考慮するなら、「デフォルトでは時間を計算するときの基点を今現在に置くが、 -daystart を指定すると、時間計算の基点が今日の 24:00 になる」と考えれば、 わかりやすいかもしれない。

非推奨である。 -L オプションを代わりに使う方がよい。 シンボリックリンクをたどる。 -noleaf が自動的に設定される。 -follow オプションが影響を及ぼすのは、コマンドラインで自分より後に指定された検査に対してだけである。 -H や -L オプションが指定されていない場合、-follow オプションの位置によって述語 -newer の動作が変わってくる。 -newer が -follow の後に来れば、-newer の引き数として指定されたいかなるファイルも、それがシンボリックリンクなら、リンクをたどられることになるわけだ。 同じことが -newerXY, -anewer, -cnewer についても言える。 同様に、述語 -type も、シンボリックリンクそのものではなく、 必ずシンボリックリンクが参照しているファイルのタイプに対してマッチを行うようになる。 -follow を使用すると、述語 -lname と -ilname は常に偽を返す。

検査 -regex と -iregex が理解する正規表現の文法を変更する。 このオプションよりコマンドラインの後方で指定する -regex などに対して効果がある。 どういう正規表現のタイプが使えるかを知るには、-regextype help を使用すればよい。 様々なタイプの正規表現が、どんなもので、どこが違うかについては、find の Texinfo 文書に説明がある (「関連項目」を参照)。

警告メッセージの表示、非表示を切り替える。 ここで言う警告とは、もっぱらコマンドラインの使用法に関するものであり、find がディレクトリを探索中に出会うかもしれない何らかの状況に関するものではない。 デフォルトの動作は、標準入力が tty であれば、-warn であり、 それ以外の場合は、-nowarn である。 コマンドラインの使用法に関する警告メッセージが生ずる場合でも、find の終了ステータスは影響を受けない。 なお、環境変数 POSIXLY_CORRECT が設定され、しかも -warn まで指定された場合に、 警告を出すとしても、どの警告を出すかは決まっていない (訳注: POSIX の規定では、find は基本的に、エラーメッセージは出しても、警告メッセージは出さないことになっている。 だから、POSIXLY_CORRECT と -warn の両方を指定するのは、使用法に混乱があるのである。 ちなみに、手元の 4.6.0 では警告は出ない)。

グローバルオプション

グローバルオプションは常に真を返す。 グローバルオプションは、コマンドライン上でそれよりも前にある検査に対しても効果を持つ。 混乱を避けるためには、グローバルオプションは、コマンドライン上で、探索開始点のリストの後ろ、 検査や位置オプションやアクションが現れる前に指定すべきである。 グローバルオプションを他の場所で指定すると、find は「混乱の元になりかねない」旨の警告メッセージを出す。

グローバルオプションの位置は、探索開始点のリストより後ろである。だから、-L などとは、まったく別種のオプションである。

-depth と同じ。FreeBSD, NetBSD, MacOS X, OpenBSD との互換性のためにある。

ディレクトリそのものより先に、ディレクトリの中身を処理する。 アクション -delete を使用すると、-depth オプションも自動的に設定される。

find のコマンドラインの使用法をざっと説明して終了する。

通常、find は stat 関数でファイル情報を取得できなかったとき、 エラーメッセージを出すことになっている。 ところが、このオプションを指定した場合は、 find がディレクトリからファイル名を読み込んでから、そのファイルに対して stat 関数を実行しようとするまでの間に、ファイルが消去されても、エラーは表示されない。 この動作は、コマンドラインで名前を指定したファイルやディレクトリに対しても適用される。 このオプションは コマンドラインを読み込む際に有効になるので、 ファイルシステムのある部分をこのオプションを有効にして探索し、 別の部分はこのオプションを無効にして探索するといったことはできない (そうしたことをやりたかったら、 find コマンドを二回実行する必要があるだろう。 一回目は、このオプションを付けて、もう一回はこのオプションなしで)。

探索開始点から最大 levels 段階下のディレクトリまで探索する (levels は非負の整数)。 -maxdepth 0 を指定すると、検査やアクションの対象になるのは、探索開始点だけになる。
探索開始点から少なくとも levels 段階ディレクトリを下降するまで、いかなる検査やアクションも行わない (levels は非負の整数)。 -mindepth 1 を指定すると、探索開始点を除くすべてのファイルを処理することになる。

ほかのファイルシステムにあるディレクトリを探索しない。これは -xdev の別名であり、系統の違う find との互換性のためにある。

-ignore_readdir_race の効果を無効にする。

「ディレクトリのハードリンク数から 2 を引いたものが、そのディレクトリに含まれるサブディレクトリの数である」とする最適化動作を行わない。 このオプションが必要になるのは、ディレクトリとリンクの関係について Unix の流儀に従わないファイルシステムを探索するときだ。たとえば、CD-ROM や MS-DOS のファイルシステムとか、AFS ボリュームのマウントポイントなどを探索するときである。 通常の Unix ファイルシステムでは、各ディレクトリは少なくとも 2 個のハードリンクを持っている。 ディレクトリ名のエントリと、そのディレクトリ中の `.' エントリである。 さらに、そのディレクトリにサブディレクトリがあれば、 サブディレクトリそれぞれに、親ディレクトリにハードリンクした `..' エントリが存在する。 そこで、find としては、ディレクトリを調べる際に、ディレクトリのハードリンク数より 2 だけ少ない数のサブディレクトリを stat 関数で調べた時点で、ディレクトリ中の残りのエントリはディレクトリではない (ディレクトリツリー中の枝ではなく、「葉っぱ (leaf)]」ファイルである) とわかるわけだ。 もし、調べるのがファイル名だけで充分なら、ファイルに対して stat 関数を実行する必要はもうない。 そこで、この最適化動作によって、検索速度がいちじるしく向上するわけである。

find のバージョンを表示して終了する。

ほかのファイルシステムにあるディレクトリを探索しない。

検査 (TESTS)

検査の中には、たとえば -newerXY や -samefile のように、現在検査の対象になっているファイルと、コマンドラインで指定したリファレンスファイルとを比較することになっているものがある。 そうしたリファレンスファイルが実際には何を指すかは、-H, -L, -P といったオプションや、先行する -follow の存在によって決まってくる。 ただし、リファレンスファイルが調べられるのは、一回だけであり、それはコマンドラインの解析が行われるときである。 リファレンスファイルを調べることができない場合は (たとえば、それに対する stat(2) システムコールに失敗するなど)、エラーメッセージが表示され、find は 0 以外のステータスで終了する。

数値の引き数は、以下の形で指定することができる。

+n
n より大きい。
-n
n より小さい。
n
ちょうど n。
ファイルの最終アクセス日時が n 分前であれば真を返す。

ファイルの最終アクセス日時が、file の内容更新日時よりも新しければ、真を返す。 引き数 file がシンボリックリンクで、しかも -H や -L オプションが有効になっている場合は、 リンク先のファイルの内容更新日時が比較に使用されることになる。

ファイルの最終アクセス日時が、基点となる時刻から計算して n 日前に当たれば、真を返す (訳注: 基点となる時刻は、デフォルトでは find を実行している今現在である)。 ファイルの最終アクセス日時が何日前かを計算する際、時間差を 24 時間で割って出た小数点以下の端数は無視される。従って、-atime +1 にマッチするためには、ファイルは少なくとも二日前にアクセスされていなければならない。 (訳注: 1.5 日前は、1 日前と判定される。そして、-atime +1 は、2 日以上前である。 なお、デフォルトの動作のように、現在時刻から数えて 24 時間前から 48 時間前までを 1 日前とするのではなく、今日の午前 0 時以前の 24 時間 (つまり、日常的な意味での昨日) を 1 日前として計算したいのなら、位置オプション -daystart を -atime の前に置けばよい。)

ファイルの最終ステータス変更日時が n 分前ならば真。

ファイルの最終ステータス変更日時が、file の内容更新日時よりも新しければ、真を返す。 引き数 file がシンボリックリンクで、しかも -H や -L オプションが有効になっている場合は、 リンク先のファイルの内容更新日時が比較に使用されることになる。

ファイルの最終ステータス変更日時が、基点となる時刻から計算して n 日前に当たれば、真を返す (訳注: 基点となる時刻は、デフォルトでは find を実行している今現在である)。 何日前かを計算する際、時間差を 24 時間で割った結果を丸めるせいで、 ファイルのステータス変更日時の解釈にどんな影響が出るかについては、 -atime の説明を参照していただきたい。 (訳注: 要するに、割り算の際に、小数点以下の端数を切り捨てるということ。 なお、デフォルトの動作のように、現在時刻から数えて 24 時間前から 48 時間前までを 1 日前とするのではなく、今日の午前 0 時以前の 24 時間 (つまり、日常的な意味での昨日) を 1 日前として計算したいのなら、位置オプション -daystart を -ctime の前に置けばよい。)

ファイルが空で、通常のファイルかディレクトリならば真。

実行可能なファイルや (ファイル名解決の見地から見て) 検索可能なディレクトリにマッチする。 検査 -perm が ACL (アクセス・コントロール・リスト) などのパーミッション制御の仕組みを無視するのに対して、この検査は ACL なども考慮に入れる。この検査は access(2) システムコールを使用しているので、UID マッピング (または root-squashing) を行っている NFS サーバがあると、正確な結果を得られないことがある。なぜなら、たいていのシステムでは access(2) をクライアントのカーネルで実装しており、それ故、サーバ側に保持されている UID マッピング情報を利用できないからだ。この検査はひとえに access(2) システムコールの結果に基づいているので、 この検査が真を返したからと言って、そのファイルが実際に実行できるとはかぎらない。

常に偽を返す。

ファイルが置かれているファイルシステムが type ならば、真を返す。 有効なファイルシステムは、Unix の系統によって様々である。 Unix の系統次第で指定可能なファイルシステムを不完全ながら挙げると、 ufs, 4.2, 4.3, nfs, tmp, mfs, S51K, S52K などがある。アクション -printf で書式指定子 %F を使えば、現在使用中のファイルシステムのタイプが何かを知ることができる。

ファイルのグループ ID 番号が n ならば真。

ファイルの属するグループが gname ならば真 (グループ ID 番号で指定してもよい)。

-lname と同じだが、大文字小文字を区別しない。-L や -follow オプションが有効な場合は、シンボリックリンクがリンク切れしている場合を除き、この検査は偽を返す。

-name と同じだが、大文字小文字を区別しない。 たとえば、パターン `fo*' や `F??' は、`Foo', `FOO', `foo', `fOo' といったファイル名とマッチする。パターン `*foo*' は、`.foobar' というファイルともマッチすることになる。

ファイルの inode 番号が n ならば真。 たいていの場合、この検査より、-samefile を使った方が簡単である。

-path と同じだが、大文字小文字を区別しない。

-regex と同じだが、大文字小文字を区別しない。

-ipath 参照。この別名は移植性で -ipath に劣る。

ファイルのハードリンク数が n ならば真。

ファイルがシンボリックリンクであり、リンク先として指定されているパスがシェルのパターン pattern にマッチすれば、真を返す。メタ文字は、`/' や `.' を例外扱いしない。 -L や -follow オプションが有効な場合は、シンボリックリンクがリンク切れしている場合を除き、この検査は偽を返す。

ファイルの最終内容更新日時が n 分前であれば真。

ファイルの最終内容更新日時が、基点となる時刻から計算して n 日前に当たれば、真を返す (訳注: 基点となる時刻は、デフォルトでは find を実行している今現在である)。 何日前かを計算する際、時間差を 24 時間で割った結果を丸めるせいで、 ファイルの内容更新日時の解釈にどんな影響が出るかについては、 -atime の説明を参照していただきたい。 (訳注: 要するに、割り算の際に、小数点以下の端数を切り捨てるということ。 なお、デフォルトの動作のように、現在時刻から数えて 24 時間前から 48 時間前までを 1 日前とするのではなく、今日の午前 0 時以前の 24 時間 (つまり、日常的な意味での昨日) を 1 日前として計算したいのなら、位置オプション -daystart を -mtime の前に置けばよい。)

ファイルやディレクトリのベースネーム (パスから最後の要素だけを残して、先行するディレクトリを取り去ったもの) が、シェルのパターン pattern にマッチすれば、真を返す。検査 -name でマッチするかどうかを調べられるファイル名は、先行するディレクトリを除去したものだから、スラッシュが含まれることはない。従って、`-name a/b' は何にもマッチしないことになる (-name ではなく、多分 -path を使う必要があるだろう)。そんなことをしようとすると、環境変数 POSIXLY_CORRECT が設定されていない場合は、警告メッセージが出る。メタ文字 (`*', `?', `[]') は、ベースネームの先頭にある `.' とマッチする (findutils-4.2.2 からこのように変更になった。下記のセクション「規格への準拠」を参照)。 あるディレクトリとそれ以下にあるファイルをまとめて無視するには、-prune を使うとよい。 一例が -path の説明中にある。波カッコ ('{}') は特殊文字として認識されない。 この点、bash を含む一部のシェルで、シェル・パターン中の波カッコに特別な意味を付与しているのと異なっている。 ファイル名のマッチングは、fnmatch(3) ライブラリ関数を用いて行われる。 パターンを引用符で囲むのを忘れないように。シェルによって展開されてしまわないようにするためである。

ファイルが file よりも最近に内容を更新されていれば、真を返す。 引き数 file がシンボリックリンクで、しかも -H や -L オプションが有効になっている場合は、リンク先のファイルの内容更新日時が比較に使用されることになる。

検査対象ファイルのタイムスタンプの X 日時が、リフェレンスファイル reference のタイムスタンプの Y 日時より新しければ、真を返す。 X と Y の位置に来る文字は、以下のどの文字でもよい。

a ファイルのアクセス日時
B ファイルの作成日時
c inode のステータスが変更された日時
m ファイルの内容が更新された日時
t reference が日時の直接表現として解釈される

組み合わせによっては、無効なものもある。たとえば、X に t を指定しても無効である。 組み合わせの中には、すべてのシステムで実装されているとはかぎらないものもある。 たとえば、B はすべてのシステムでサポートされているわけではない。 XY の無効な組み合わせやサポートされていない組み合わせを指定すると、致命的エラーが生じる。 日時を直接指定すると、それは GNU date の -d オプションに対する引き数と同じように解釈される。 リファレンスファイルの作成日時を使用しようとした場合に、作成日時が特定できないと、致命的エラーのメッセージが出力される。 また、検査対象ファイルの作成日時を参照する検査を指定した場合に、 作成日時がわからない環境では、その検査はいかなるファイルに対しても失敗することになる (訳注: この場合、失敗するというのは、検査が偽になることではなく、エラーになることのようだ。ご自分の環境で確かめていただきたい)。

ファイルのグループ ID 番号に対応するグループが、システムに存在しない場合に、真を返す。

ファイルのユーザ ID 番号に対応するユーザが、システムに存在しない場合に、真を返す。

ファイル名がシェルのパターン pattern にマッチすれば、真を返す。 メタ文字は、`/' や `.' を例外扱いしない。従って、たとえば、

find . -path "./sr*sc"

は、`./src/misc' というディレクトリを (存在していれば) 表示することになる。 あるディレクトリ以下をすべて無視するには、そこに存在するファイルを一つ一つ抑止するよりも、-prune を使用した方がよい。たとえば、ディレクトリ `src/emacs' と、その下にあるファイルやディレクトリのすべてをスキップし、それ以外のファイルが見つかったら、その名前を表示するとしよう。そのためには、こんな風にする。

find . -path ./src/emacs -prune -o -print

パターンマッチの検査は、パスを含むファイル名の全体に対して行われるが、 そうしたファイル名は、コマンドラインで指定した探索開始点の一つから始まっていることに注意してしていただきたい。 だから、-path の引き数に絶対パス名を使用することに意味があるのは、 関連する探索開始点がこちらも絶対パスであるときだけだろう。 従って、次のコマンドは 何にもマッチしないことになる。

find bar -path /foo/bar/myfile -print

find は、-path の引き数を、目下検査してるファイルのディレクトリ名とベースネームを連結したものと比較する。 その連結したものの末尾がスラッシュになることは絶対にないので、スラッシュで終わる -path の引き数は、何にもマッチしないことになる (ただし、コマンドラインで指定された探索開始点となら、場合によってはマッチするかもしれないが)。 -path という述語は、HP-UX の find でもサポートされており、 POSIX 規格の次期バージョンでも採用されることになるだろう (訳注: 実際に POSIX 2008 で採用されている)。

ファイルの許可属性が mode (8 進数表現でもシンボル表現でもよい) とまったく同じなら、真を返す。 mode 指定のこの形式では、許可属性がぴったり一致することを要求することになるので、 シンボルによる表現でこの形式を使おうとすると、かなり複雑なモード文字列を指定しなければならないかもしれない。 たとえば `-perm g=w' は、許可属性が 0020 のファイルにしかマッチしない (すなわち、許可属性のうち、グループの書き込み許可のみが立っているファイルだ)。 従って、mode の前に `/' や `-' を付ける形式を使いたくなることの方が、多分多いだろう。 たとえば、`-perm -g=w' とすれば、グループの書き込み許可があるファイルなら、どんなファイルにもマッチすることになる。 具体例については「用例」セクションをご覧いただきたい。

mode で指定した許可属性ビットのすべてが、ファイルでも立っていれば、真を返す。 mode 指定のこの形式でも、シンボルによる許可属性表現が使用できる。 そこで、この形式ではシンボルによる表現を使いたくなることが多いだろう。 シンボルによる表現を使用する場合は、`u' や `g' や `o' を きちんと指定しなければならない。 具体例については「用例」セクションをご覧いただきたい。

mode で指定した許可属性ビットのどれかが、ファイルでも立っていれば、真を返す。 mode 指定のこの形式でも、シンボルによる許可属性表現が使用できる。 シンボルによる表現を使用する場合は、`u' や `g' や `o' をきちんと指定しなければならない。 具体例については「用例」セクションをご覧いただきたい。なお、mode で許可属性ビットが一つも立っていない場合、この検査はいかなるファイルにもマッチすることになる (これは、-perm -000 と動作に一貫性を持たせるための変更である。 (訳注: -perm -mode と -perm /mode のどちらの指定法においても、0 は何であってもよいを意味するようにしたということ))。

この形式は、今ではサポートされていない (2005 年以来、非推奨だった）。 代わりに -perm /mode を使用すること。

読み込み可能なファイルにマッチする。検査 -perm が ACL (アクセス・コントロール・リスト) などのパーミッション制御の仕組みを無視するのに対して、この検査は ACL なども考慮に入れる。 この検査は access(2) システムコールを使用しているので、UID マッピング (または root-squashing) を行っている NFS サーバがあると、正確な結果を得られないことがある。なぜなら、たいていのシステムでは access(2) をクライアントのカーネルで実装しており、それ故、サーバ側に保持されている UID マッピング情報を利用できないからである。

ファイル名が正規表現 pattern にマッチすれば、真を返す。 これはパスを含むファイル名全体に対するマッチであって、ベースネームの検索ではない。 だから、たとえば、`./fubar3' という名前のファイルにマッチさせるために、 正規表現 `.*bar.' や `.*b.*3' は使用できるが、`f.*r3' は使用できない。 find が理解する正規表現は、デフォルトでは Emacs の正規表現だが、 これは -regextype オプションで変更することができる。

ファイルが name と同じ inode を参照していれば、真を返す。 -L が有効な場合、シンボリックリンクも真を返す。

ファイルが n 単位分の領域を使用していれば、真を返す (対象となるファイルのサイズを、単位にまで切り上げて比較する)。以下の接尾辞が使える。
[訳注]:
ブロック数を指定するときは、注意していただきたい。 -size では、検査対象ファイルのブロック数の算出を、単にファイルのサイズを 512 で割り、その結果を切り上げて整数にすることで行っている。 これは、stat コマンドの出力や POSIXLY_CORRECT が設定されているときの ls -s の結果と、同じではないことが多い。stat や ls は、ファイルに対するディスクスペースの割当が、ファイルシステムのブロックサイズ (ext4 なら、たいてい 4096 バイト、つまり 8 ブロック) の倍数で行われることを考慮に入れているのである。なお、アクション -printf における `%b' の出力は、stat などと同じである。
`b'
単位はブロック。1 ブロックは 512 バイト。(これが接尾辞を使わないときの デフォルトである)
`c'
単位はバイト。
`w'
単位はワード。1 ワードは 2 バイト。
`k
単位はキビバイト (1 キビバイトは 1024 バイト)。
`M'
単位はメビバイト (1 メビバイトは 1048576 バイト)。
`G'
単位はギビバイト (1 ギビバイトは 1073741824 バイト)。
サイズには間接ブロック (indirect block) の分は含まれないが、穴空きファイル (sparse file) における、実際には割り当てられていないブロックの分は含まれる。 アクション -printf の `%k' や `%b' 書式指定子とは、穴空きファイルの扱い方が違うことを心にとめておいていただきたい。 また、接尾辞 `b' は常に 512 バイトのブロックを意味し、1 キロバイトのブロックを指すことはない。 その点で、アクション -ls の動作とは異なっている。 数値の前に + や - を付けると、他の場合と同様、「より大きい」や「より小さい」を意味することになるが、 ファイルのサイズは、単位以下の部分が、単位にまで切り上げられることに留意していただきたい (だから、1 byte のファイルは、-size -1M にマッチしない。(訳注: -size 1M とならマッチする))。
常に真。

ファイルのタイプが c であれば真。(訳注: c の位置には実際には以下の文字が来る。)
ブロック・スペシャルファイル (バッファあり)
キャラクタ・スペシャルファイル (バッファなし)
ディレクトリ
名前付きパイプ (FIFO)
通常のファイル
シンボリックリンク。オプション -L や -follow が有効な場合、 シンボリックリンクがリンク切れの場合を除いて、この検査が真になることはない。 -L が有効なときにシンボリックリンクを検索したかったら、-xtype を使うべきである。
ソケット
ドア (Solaris の場合)
ファイル所有者のユーザ ID 番号が n ならば真。

ファイルが最後にアクセスされたのが、ファイルの最終ステータス変更日時より n 日後ならば、真を返す。

ファイルの所有者が uname というユーザならば真 (ユーザ ID 番号で指定してもよい)。

-path と同じである。この別名は移植性で -path に劣る。

書き込み可能なファイルにマッチする。検査 -perm が ACL (アクセス・コントロール・リスト) などのパーミッション制御の仕組みを無視するのに対して、 この検査は ACL なども考慮に入れる。この検査は access(2) システムコールを使用しているので、UID マッピング (または root-squashing) を行っている NFS サーバがあると、正確な結果を得られないことがある。なぜなら、たいていのシステムでは access(2) をクライアントのカーネルで実装しており、それ故、サーバ側に保持されている UID マッピング情報を利用できないからである。

検査の対象となるファイルがシンボリックリンクでないかぎり、-type と同じである。 ファイルがシンボリックリンクのときは、以下のように動作する。 -H や -P オプションが指定された場合は、タイプが c のファイルに対するリンクならば、真を返す。また、-L オプションが指定されている場合は、c が `l' ならば、真を返す。 言い換えると、ファイルがシンボリックであるとき、-xtype は、-type がチェックしない方のファイルのタイプをチェックするわけだ。
(SELinux が有効なときのみ) ファイルのセキュリティ・コンテキストが glob のパターン (訳注: つまり、シェル式のパターン) pattern にマッチすれば、真を返す。

アクション

ファイルを消去する。消去に成功すれば、真を返す。 消去に失敗した場合は、エラーメッセージを表示する。 -delete に失敗した場合の find の終了ステータスは、ゼロ以外である (find が最終的に終了したときの終了ステータスのことだ)。-delete を使用すると、自動的に `-depth' オプションが有効になる。

警告: 忘れないでいただきたいが、find のコマンドラインは一つの式 (expression) として評価されるので、一番最初に -delete を指定すると、 find は、指定された探索の開始点以下にあるものを、ことごとく消去しようとする。 後で -delete を付けて使用するつもりで、find のコマンドラインをテスト実行するときは、-depth を明示的に指定するとよい。 そうすれば、後で「こんなはずではなかった」と慌てないですむ。 -delete を指定すると自動的に -depth が有効になるので、-prune を -delete と一緒に使っても役に立たない。

command を実行する。command の返り値が 0 ならば、真を返す。 find のコマンドラインで指定されているこれ以降の引き数は、`;' という引き数が現れるまで、すべてコマンドに対する引き数と見なされる。 文字列 `{}' は、それがコマンドの引き数中に現れるすべての場所で、現在処理中のファイル名に置き換えられる。 find の一部の版とは違い、`{}' は引き数中の一ヶ所でしか使えないわけではない。 こうした構文の要素 (訳注: すなわち、`{}' や `;') は、シェルによって展開されないように、 どちらも `\' でエスケープするなり、引用符で囲むなりする必要があるかもしれない。 アクション -exec の使用例については「用例」セクションを見ていただきたい。 指定したコマンドは、マッチした各ファイルに対して一回づつ実行される。 また、コマンドは find を実行したディレクトリで実行される。 そこで、-exec アクションの使用を巡っては、セキュリティの問題が避けられないわけであり、 -exec の代わりに、-execdir アクションを使用することをお勧めする。 (訳注: `;' は引き数なので、直前の引き数との間に空白が必要だということに注意していただきたい。)

アクション -exec のこの変形も、選択したファイルに対して指定したコマンドを実行するが、 コマンドラインを形成するとき、選択した各ファイル名をコマンドラインの末尾に追加して行くという方法を取る (訳注: コマンドラインが長くなりすぎるときは、処理するファイル名のリストを適宜分割して、コマンドを複数回実行する)。 そのため、コマンドを呼び出す回数が、マッチしたファイルの数よりずっと少なくてすむ。 コマンドラインの形成法は、 xargs のコマンドライン形成法とほぼ同じである。 `{}' はコマンドライン中の一ヶ所でしか使えない。 なお、コマンドは find を実行したディレクトリで実行される。 find がエラーに出会うと、このアクションは find をその場で終了させてしまうことがあり、 そのため、予定されているコマンドの中に全く実行されないものが生ずるかもしれない。 -exec のこの変形は、常に真を返す。 (訳注: `+' は引き数なので、直前の引き数との間に空白が必要だということに注意していただきたい。)

-exec と似ているが、指定したコマンドを、マッチしたファイルが存在するサブディレクトリで実行するという点が異なっている。 そのサブディレクトリは、 find を実行したディレクトリとは違うのが普通だ。 これはコマンドを呼び出す方法としてずっと安全である。マッチしたファイルのパスを解決する際に、競合状態が起きるのを避けられるからだ。 アクション -exec の場合と同様、 -execdir の `+' を伴う形式でも、 マッチした複数のファイルを一度に処理するように、コマンドラインを形成することになるが、 command のどの呼び出しにおいても、処理の対象としてリストされるファイルは、同じサブディレクトリに存在するものだけである。 このアクションを使用するのなら、環境変数 $PATH が `.' を参照しないようにしなければならない。 さもないと、悪意を持った攻撃者が、あなたが -execdir を実行することになるディレクトリに適当な名前のファイルを入れておくことによって、 何でも好きなコマンドを実行できてしまうからだ。 $PATH の中に、空っぽのエントリや、絶対パスのディレクトリ名ではないエントリがある場合にも、同じことが言える。 find がエラーに出会うと、このアクションは find をその場で終了させてしまうことがあり、 そのため、予定されているコマンドの中に全く実行されないものが生ずるかもしれない。 このアクションが返す値は、+ と ; のどちらを使うかによって異なっている。 -execdir command {} + が常に真を返すのに対して、-execdir command {} ; は、command が 0　を返したときのみ、真を返すのである。

真を返す。-ls と似ているが、-fprint 同様、出力を file に書き出す点が違う。 出力用のファイルは、この述語の対象になるものが一つもなかった場合でも、必ず作成される。 ファイル名中の普通使わない文字がどのように扱われるかについては、「変わり者のファイル名」セクションを参照していただきたい。

真を返す。パス付きのファイル名をファイル file に出力する。 find の実行時に file が存在しなければ、新たに作成される。 すでに存在していれば、元の中身が捨てられる。ファイル名 `/dev/stdout' と `/dev/stderr' の扱いは特別で、それぞれ標準出力と標準エラー出力を指している。 出力用のファイルは、この述語の対象になるものが一つもなかった場合でも、必ず作成される。 ファイル名中の普通使わない文字がどのように扱われるかについては、「変わり者のファイル名」セクションを参照していただきたい。

真を返す。-print0 と似ているが、-fprint 同様、出力を file に書き出す点が違う。 出力用のファイルは、この述語の対象になるものが一つもなかった場合でも、必ず作成される。 ファイル名中の普通使わない文字がどのように扱われるかについては、「変わり者のファイル名」セクションを参照していただきたい。

真を返す。-printf と似ているが、 -fprint 同様、出力を file に書き出す点が違う。 出力用のファイルは、この述語の対象になるものが一つもなかった場合でも、必ず作成される。 ファイル名中の普通使わない文字がどのように扱われるかについては、「変わり者のファイル名」セクションを参照していただきたい。

真を返す。処理対象のファイルを ls -dils の書式で標準出力にリストする。 ブロック数は、1 ブロック 1 キロバイトの計算である。 ただし、環境変数 POSIXLY_CORRECT が設定されている場合は、1 ブロック 512 バイトが使用される。 ファイル名中の普通使わない文字がどのように扱われるかについては、「変わり者のファイル名」セクションを参照していただきたい。

-exec と似ているが、まずユーザに問い合わせを行う。 ユーザーが同意すれば、コマンドを実行する。同意しなければ、何もせずに偽を返す。 コマンドを実行する場合、そのコマンドの標準入力は、/dev/null に付け換えられる。

プロンプトに対するユーザの応答は、肯定・否定を表す一組の正規表現と照合して、同意か、不同意かが判断される。 この正規表現は、環境変数 `POSIXLY_CORRECT' が設定されていれば、システムから得られるが、 設定されていなければ、find の持つメッセージ翻訳から取得される。 なお、システムに適切な定義が存在しない場合は、 find の持つ定義が使用されることになる。 どちらの場合でも、正規表現そのものの解釈は、環境変数 'LC_CTYPE' (文字クラスについて) や 'LC_COLLATE' (文字の範囲や等価クラスについて) の影響を受ける。

-execdir と似ているが、-ok と同じように、まずユーザに問い合わせを行う。 ユーザが同意しなければ、何もせずに偽を返す。 コマンドを実行する場合、そのコマンドの標準入力は、/dev/null に付け換えられる。

真を返す。パス付きのファイル名を標準出力に表示し、各ファイル名の後ろに改行文字を付ける。 find の出力をパイプを使って他のプログラムに渡している場合、 検索対象のファイル名に改行文字が含まれている可能性が、わずかにでもあるならば、 -print ではなく、 -print0 アクションを使用することを真剣に考えるべきだ。 ファイル名中の普通使わない文字がどのように扱われるかについては、「変わり者のファイル名」セクションを参照していただきたい。

真を返す。パス付きのファイル名を標準出力に表示し、各ファイル名の後ろに (-print が改行文字を付けるのとは違って) ヌル文字を追加する。 このアクションを使えば、find の出力を処理するプログラムが、改行文字などのホワイトスペースを含むファイル名を正しく解釈できるようになる。 このアクションは、xargs の -0 オプションに呼応している。

真を返す。標準出力に format を表示する。そのとき format 中の `\' によるエスケープシーケンスと、`%' に始まる書式指定子を認識して変換する。 フィールドの幅や精度は、C 言語の `printf' 関数と同じ方法で指定できる。 %d ではなく、%s として (訳注: すなわち、数値ではなく、文字列として) 表示されるフィールドが多いことに注意していただきたい。 そのため、フラグが期待通りに効かないかもしれないのだ。 ただし、`-' フラグ (フィールドを強制的に左揃えにする) はきちんと働くということでもある。-print とは違って、 -printf は文字列の末尾に改行文字を追加しない。 バックスラッシュ・エスケープシーケンスと書式指定子は以下のとおりである。
警告ベル。
バックスペース。
このフォーマットによる出力をただちに停止し、出力をフラッシュする。
フォームフィード文字。
改行文字。
復帰文字。
水平タブ。
垂直タブ。
\0
ASCII NUL 文字。
\\
バックスラッシュ文字そのもの (`\')。
ASCII コードが NNN (8 進数) の文字。

バックスラッシュ文字 `\' に上記以外の文字が続く場合、`\' は普通の文字として扱われる。 従って、二文字とも表示されることになる。

%%
パーセント文字そのもの。
%a
ファイルの最終アクセス日時を C 言語の `ctime' 関数が返す形式で表示する。
%Ak
ファイルの最終アクセス日時を k で指定した書式で表示する。k には `@' か、あるいは C 言語の `strftime' 関数の書式指定子を用いる。 k に指定可能な値を以下に列挙する。 一部のものは使えないシステムがあるかもしれないが、それはシステム間での `strftime' の非互換性による。
@
Jan. 1, 1970, 00:00 GMT からの経過秒数。小数点以下も表示する。

時刻フィールド:

時 (00..23)
時 (01..12)
時 ( 0..23)
時 ( 1..12)
分 (00..59)
現在のロケールにおける AM/PM の相当語
12 時間制の時刻 (hh:mm:ss [AP]M)
秒 (00.00 .. 61.00)。小数点以下も表示。
24 時間制の時刻 (hh:mm:ss)
+
日付と時刻。両者の間は `2004-04-28+22:22:05.0' といった具合に '+' で 区切られる。 これは GNU の拡張である。日時は現在のタイムゾーンのものが使われる (それ故、環境変数 TZ の設定によって変わるかもしれない)。秒には小数点以下も付く。
現在のロケールによる時刻表示 (H:M:S)
タイムゾーン (JST など)。タイムゾーンを決定できない場合は、何も表示しない。

日付フィールド:

現在のロケールによる曜日の短縮形 (Sun..Sat)
現在のロケールによる曜日の省略しない表示。長さは可変 (Sunday..Saturday)
現在のロケールによる月名の短縮形 (Jan..Dec)
現在のロケールによる月名の省略しない表示。長さは可変 (January..December)
現在のロケールによる日付と時刻の表示 (Sat Nov 04 12:02:33 EST 1989)。 この表示形式は ctime(3) のものと同じであり、ctime(3) の形式との互換性を維持するためにそうなっている。秒には小数点以下が付かない。
その月の何日目かの表示 (01..31)
日付 (mm/dd/yy)
b と同じ
その年の何日目かの表示 (001..366)
月 (01..12)
その年の何週目か (日曜日を週の始まりとする) (00..53)
曜日 (0..6)
その年の何週目か (月曜日を週の始まりとする) (00..53)
現在のロケールによる日付表示 (mm/dd/yy)
年の下二桁 (00..99)
年 (1970...)
%b
ファイルのディスクスペース使用量を 1 ブロック 512 バイトのブロック数で表示する。 ディスクスペースは、ファイルシステムのブロックサイズの倍数で割り当てられるので、この表示はたいてい %s/512 より大きい。だが、ファイルが穴空きファイル (sparse file) の場合は、%s/512 より小さくなることもある。
%c
ファイルの最終ステータス変更日時を C 言語の `ctime' 関数が返す形式で表示する。
%Ck
ファイルの最終ステータス変更日時を k で指定した書式で表示する。 k は %A の場合と同じである。
%d
ファイルがディレクトリツリー中でどの深さにあるかを示す。 0 だったら、そのファイルが探索開始点だということだ。
%D
ファイルがどのデバイス上にあるかを十進数のデバイス番号で示す (stat 構造体の st_dev フィールドに当たる)。
%f
先行するディレクトリをすべて取り去ったファイル名 (すなわち、最後の要素のみ表示)。
%F
ファイルが置かれているファイルシステムのタイプ。ここで表示された値は -fstype の引き数に指定することができる。
%g
ファイルのグループ名。該当するグループ名が存在しない場合は、グループ ID 番号。
%G
ファイルのグループ ID 番号。
%h
ファイル名中の先行するディレクトリの部分 (すなわち、最後の要素以外のすべて)。 ファイル名にスラッシュが一つも含まれない場合は (それは、カレントディレクトリ中にあるということだから)、%h 書式指定子は "." に展開される。
%H
探索開始点のうち、その下に問題のファイルが見つかったもの。
%i
ファイルの inode 番号 (十進数表示)。
%k
ファイルのディスクスペース使用量を 1 ブロック 1 キロバイトのブロック数で表示する。 ディスクスペースは、ファイルシステムのブロックサイズの倍数で割り当てられるので、この表示はたいてい %s/1024 より大きい。 だが、ファイルが穴空きファイル (sparse file) の場合は、%s/1024 より小さくなることもある。
%l
シンボリックリンクの参照先 (ファイルがシンボリックリンクでなかったら、空文字列)。
%m
ファイルの許可属性ビット (8 進数表示)。このオプションが使用している数値は、 Unix のたいていの実装が使用している「伝統的な」数値である。 しかし、ご使用のシステムの実装では、8 進数で表示する許可属性ビットの並び方が独特かもしれない。 その場合は、ファイルの許可属性の実際の値と %m の出力とが、相違することになる。 この数値の先頭に 0 を付けて表示したいこともよくあるが、 そのためには、# フラグを使用すればよい (たとえば、`%#m' といった具合に)。
%M
ファイルの許可属性 (ls と同様のシンボルによる表現)。この書式指定子は findutils 4.2.5 以来 サポートされている。
%n
ファイルのハードリンク数。
%p
ファイル名。
%P
問題のファイルが、ある探索開始点の下にあった場合に、 ファイル名から探索開始点を示す部分を取り去ったもの。
%s
バイトで表示したファイルサイズ。
%S
ファイルの穴空き率 (sparseness)。この値は、(BLOCKSIZE*st_blocks / st_size) で計算される。ある大きさの普通のファイルから得られる値は、厳密に言うと、システム依存である。 それでも、穴空きファイルの穴空き率は、通常 1.0 未満になるし、 間接ブロックを使用しているファイルの穴空き率は、1.0 以上になることがある。 BLOCKSIZE に使われる値は、システム次第だが、普通は 512 バイトである。 ファイルサイズが 0 の場合、出力される値は不定である。 st_blocks をサポートしていないシステムでは、ファイルの穴空き率は、1.0 と見なされる。
%t
ファイルの最終内容更新日時を、C 言語の `ctime' 関数が返す形式で表示する。
%Tk
ファイルの最終内容更新日時を k で指定した書式で表示する。 k は %A の場合と同じである。
%u
ファイルの所有者名。該当するユーザ名が存在しない場合は、ユーザ ID 番号。
%U
ファイルのユーザ ID 番号。
%y
ファイルのタイプ (ls -l の表現とほぼ同じ)。U=unknown type (これが表示されることはないはずだ）
%Y
ファイルのタイプ (表示は %y と同じ)。ただし、シンボリックリンクをたどる。 その場合、L=loop, N=nonexistent である。
%Z
(SELinux が有効なときのみ) ファイルのセキュリティ・コンテクスト。
%{ %[ %(
将来の使用のために予約されている。

一個の `%' に上記以外の文字が続く場合、`%' 文字は捨てられるが、それに続く文字は表示される (書式指定文字が新たに追加されるかもしれないので、この動作を当てにしてはいけない。 (訳注: 以前はそのとおりだったが、現在では、無効な書式指定子を使った場合、`%q' のように `%' も表示されるようだ))。 書式指定の末尾に `%' があるときの動作は、続く文字がないので不定である。 ロケールによっては、お宅のドアの鍵が見つからなくなるかもしれない。 また、別のロケールでは、お読みになっている小説の最後のページが消えてしまうかもしれない。

書式指定子 %m と %d はフラグ #, 0, + をサポートするが、 それ以外の書式指定子では、数値を表示する場合でも、そうしたフラグをサポートしない。 # などをサポートしない数値関係の書式指定子には、G, U, b, D, k, n などがある。しかし、書式フラグ `-' はサポートされており、フィールドを (デフォルトの) 右揃えから左揃えに変更する。

ファイル名中の普通使わない文字がどのように扱われるかについては、 「変わり者のファイル名」セクションの説明を参照していただきたい。

真を返す。処理対象のファイルがディレクトリの場合は、そのディレクトリ以下に降りて行かない。 -depth が指定してあると、-prune は、 偽を返し、その効果を失う。-delete を指定すると自動的に -depth が有効になるので、-prune を -delete と一緒に使っても役に立たない。

[訳注]:
つまり、-prune は指定されたディレクトリの、いわゆる枝刈り (prune) をする。バージョン 4.3.11 以降の find では、-prune の動作が、上の説明と少し違っている。-depth が指定してあると、-prune が効果を失う (すなわち、枝刈りを行わなくなる) ことは、それ以前と変わりがないが、返り値は真を返すようになっているのだ。 これは POSIX 準拠の動作である。ご自分で、 find . -depth -path "./foo" -prune -print などを実行して、確認していただきたい。-prune が真を返していれば、ディレクトリ ./foo が表示されるはずである。
直ちに終了する。動いている子プロセスを残したまま終了したりはしないが、コマンドラインで指定したパスをこれ以上処理することはない。 たとえば、 find /tmp/foo /tmp/bar -print -quit は、/tmp/foo を表示するだけである。 -execdir ... {} + によってすでに作成されたコマンドラインがあれば、 find が終了する前に、呼び出して実行する。 終了ステータスは、 エラーがすでに起きているかどうかよって、0 のことも、0 でないこともある。

演算子

演算子を優先順位の高いものから順に列挙する。

( expr )
カッコの内側を先に処理する。カッコはシェルにとって特別な意味を持っているので、普通はクォートする必要があるだろう。 このマニュアルページで挙げている例の多くでは、そのためにバックスラッシュを使っている。 すなわち `(...)' ではなく、`\(...\)' と書いている。

! expr
expr が偽の場合、真になる。 通常、この記号もシェルによって解釈されないようにする必要があるだろう。

! expr と同じだが、POSIX 準拠の表現ではない。

連続する二つの式は、and 結合と解釈される (明示されていないが、式の間に "-a" があると見なされるわけだ)。expr1 が偽の場合、expr2 は評価されない。

expr1 expr2 と同じ。

expr1 expr2 と同じだが、POSIX 準拠の表現ではない。

or 結合である。expr1 が真ならば、expr2 は評価されない。

expr1 -o expr2 と同じだが、POSIX 準拠の表現ではない。

リストである。常に expr1 と expr2 の両方が評価される。 expr1 の値は捨てられ、expr2 の値がリスト全体の値になる。 コンマ演算子はいくつかの異なったタイプの対象を捜すとき便利だが、ファイルシステム階層の探索は一度しか行われない。 異なった形でマッチした対象の一覧をそれぞれ別の出力ファイルに書き出すには、-fprintf アクションを利用すればよい。

[訳注]:
find にとって演算子も引き数である。だから `(', `)', `!', `,' といった演算子も、 前後の引き数との間に空白が必要だということに気をつけていただきたい。

変わり者のファイル名

多くの場合 find のアクションは、他のユーザが自由にできるデータを端末に表示することになる。 そうしたデータには、 たとえば、ファイルの名前、サイズ、内容更新日時などがある。 この内、ファイル名は `\0' と `/' 以外のどんな文字でも使えることになっているので、時として問題の種となる。 ファイル名の中に普通は使わない文字があると、使用している端末に思いがけない、そしてしばしば望ましくない影響をもたらすことがあるのだ (たとえば、 端末によっては、ファンクション・キーの現在の設定が変更されてしまう)。 普通使わない文字をどう扱うかはアクションによって異なっている。それを以下に示そう。

常にファイル名に手を加えず、そのまま出力する。出力先が端末であっても、同じである。

普通使わない文字は、常にエスケープされる。ホワイトスペース (空白、改行、タブなど)、バックスラッシュ、ダブルクォートは C 言語式のエスケープ表現で出力される (たとえば `\f', `\"')。他の普通使わない文字には、エスケープした 8 進数が使われる。 それ以外の表示可能な文字は (-ls や -fls とっては 8 進数の 041 から 0176 に当たる文字)、手を加えずにそのまま出力される。

出力先が端末でない場合は、そのまま出力される。端末の場合は、使用される書式指定子によって、結果は様々である。 書式指定子 %D, %F, %g, %G, %H, %Y, %y が展開される値は、ファイルの所有者の管轄外なので、そのまま出力される。 書式指定子 %a, %b, %c, %d, %i, %k, %m, %M, %n, %s, %t, %u, %U の値は、ファイル所有者の管轄内ではあるが、それを使って端末に勝手なデータを送ることはできない。 従って、そのまま出力される。書式指定子 %f, %h, %l, %p, %P はクォートされる。 このクォート方法は、GNU ls と同じである (訳注: 厳密に言うと、現在のところ ls -N と同じ。ls はバージョンによっては、デフォルトの表示が -N ではないことがある)。つまり、-ls や -fls におけるクォート方法とは違うということだ。もし、find の出力に使用する形式を自由に決めることができるならば、たいていの場合、 終端文字に改行ではなく、`\0' を使用した方がよい。 ファイル名には空白や改行が含まれていることがあるからだ。 どの文字にクォートが必要かを判断するには、環境変数 `LC_CTYPE' の設定が使用される。

クォートは -printf や -fprintf と同じやり方で行われる。 find をスクリプト中で使っている場合や、マッチするファイルが我儘なファイル名を持っているかもしれない場合は、-print ではなく、 -print0 の使用を考えた方がよいだろう。

アクション -ok と -okdir は、対象となるファイル名をそのまま手を加えずに出力する。 この動作は、将来のリリースで変わるかもしれない。

規格への準拠

POSIX 規格にできるだけ準拠した動作を求めるのなら、環境変数 POSIXLY_CORRECT を設定するとよい。以下のオプションや述語は POSIX 規格 (IEEE Std 1003.1, 2003 Edition) で規定されている。

-H
このオプションはサポートしている。

-L
このオプションはサポートしている。

この述語はサポートしている。しかし、POSIX への準拠度は、システムの fnmatch(3) ライブラリ関数がどの程度 POSIX に準拠しているかに依存している。 findutils-4.2.2 以来、シェルのメタ文字 (`*', `?', `[]' など) は、 ファイル名の先頭の `.' 文字にマッチするが、これは IEEE PASC interpretation 126 がそう要求しているからである。この動作は それ以前のバージョンの findutils と異なっている。

サポートしている。POSIX では `b', `c', `d', `l', `p', `f', `s' を規定している。GNU find は、そのほか「ドア」を表す `D' もサポートしているが、 使えるのは OS がそうしたファイル・タイプを用意している場合のみである。

サポートしている。プロンプトに対する応答は、"yes"、"no" を表すパターンに照らして解釈されるが、そのパターンは、環境変数 `LC_MESSAGES' を設定することによって選択される。環境変数 `POSIXLY_CORRECT' が設定されている場合は、何が肯定的応答 (yes) で、何が否定的応答 (no) かを決めているシステムの定義が、このパターンとして使用される。 nl_langinfo(3) に関するシステムの文書、特に YESEXPR と NOEXPR の部分を参照してほしい。それに対し、`POSIXLY_CORRECT' が設定されていない場合は、 パターンは、システムではなく、find の持つメッセージ・カタログから取得されるのである。

サポートしている。指定されたファイルがシンボリックリンクの場合は、必ずリンク先が参照される (訳注: 訳者としては、「-L や -H オプションが有効な場合は」という条件が必要ではないかと思う。 -P, -L, -H オプションや、検査 -newer の説明を参照)。 以前のバージョンでは、シンボリックリンクそのものから比較に使う日時を取得していたが、 動作がこのように変更になった。後述の「履歴」セクションも参照してほしい。

サポートしている。環境変数 POSIXLY_CORRECT が設定されていない場合は、POSIX では無効な (たとえば、+a+x といった) モード指定の引き数も、後方互換のために使用できるようになっている (訳注: find 4.6.0 では、POSIXLY_CORRECT が設定されていないときでも、+a+x のような -perm +mode の形式は使えなくなっている)。

その他の述語
-atime, -ctime, -depth, -group, -links, -mtime, -nogroup, -nouser, -perm, -print, -prune, -size, -user -xdev といった述語は、すべてサポートしている。

POSIX 規格は、カッコ `(', `)'、否定 `!'、それに and と or 演算子 (-a, -o) を規定している。

上記以外のすべてのオプション、述語、式などは、POSIX 規格にない拡張である。 とは言え、そうした拡張の多くは、GNU find に特有なものではない。

POSIX 規格によれば、 find はループを検出することになっている。

find ユーティリティは無限ループを検出しなければならない。 無限ループとは、探索中に入ったディレクトリが、すでに訪れたことがあり、しかも直前に処理対象にしたファイルの上位にあるディレクトリであることである。 無限ループを検出した場合、find は何が起きたかを告げる診断メッセージを標準エラーに表示し、探索位置をディレクトリ階層上の元の位置に戻すか、終了すべきである。

GNU find はそうした要求に従っている。 ディレクトリがその中に上位ディレクトリへのハードリンクであるエントリを含んでいる場合は、 ディレクトリのハードリンク数が、そのエントリが普通のサブディレクトリならそうなるはずの数よりも、たいてい少なくなるものだ (訳注: 実際には、Linux を始め、ディレクトリのハードリンクを禁止しているシステムが多い)。その結果、 GNU find が時として、実際には上位ディレクトリへのハードリンクであるサブディレクトリを、最適化の副作用で探索しないことが起こりえる。その場合、 find は確かにそうしたディレクトリに足を踏み入れないわけだから、「ループ検出」の診断メッセージを出さないでもよいことになっている。 これはかなり紛らわしい動作かもしれないが、find のこの動作を本気で当てにしている人もいないことだろう。 -noleaf オプションを指定して、ディレクトリ・ツリー上の葉っぱを簡易判別する最適化を無効にしている場合は (訳注: -noleaf 参照)、こうしたディレクトリ・エントリに対する検査も省略されずに行われ、 必要ならば、診断メッセージが表示されることになる。シンボリックリンクを使っていれば、 ファイルシステム上に本物の循環を起こすことはないが、それでも、-L や -follow を使用している場合は、探索中にシンボリックリンクのループに出会えば、診断メッセージが表示される。 ハードリンクを含むループの場合と同様、葉っぱを簡易判別する最適化を使用していると、 find はたいていの場合、シンボリックリンクに対して stat() や chdir() を呼び出すまでもないと知っていることになるので、ループの診断は不要になることが多い。

-d オプションは BSD システム各種との互換性のためにサポートされている。 だが、POSIX に準拠している -depth オプションの方を使った方がよい。

環境変数 POSIXLY_CORRECT は、検査 -regex や -iregex の動作に影響を与えない。 そうした検査は、POSIX 規格で規定されていないからである。

環境変数

国際化関係の環境変数のうち、値が設定されていなかったり、null だったりする変数に対して、LANG の値がデフォルトの値になる。

この環境変数が空文字列以外の値に設定されていると、その値が国際化関係の他のすべての環境変数の値よりも優先される。

POSIX の規定によれば、この環境変数は検査 -name で使われるパターンマッチングに影響する。 GNU find は fnmatch(3) ライブラリ関数を使用しているので、LC_COLLATE への対応はシステムのライブラリ次第である。また、この変数はアクション -ok に対する応答の解釈にも影響を及ぼす。 -ok に対する応答の解釈に使用される実際のパターンは LC_MESSAGES 変数によって選択されるのだが、そのパターン中に角カッコ式が使われている場合の解釈は、LC_COLLATE の影響を受けるのである。

この環境変数は、正規表現で使用される文字クラスの処理に影響する。 システムの fnmatch(3) ライブラリ関数が対応している場合は、検査 -name で使われる文字クラスの処理にも影響を及ぼす。また、この変数は、アクション -ok が出すプロンプトに対してユーザが応答する際、諾否の判断に使用される正規表現に文字クラスが使われていれば、 その解釈にも影響する。さらにまた、環境変数 LC_CTYPEは、ファイル名が表示されるとき、どの文字を表示不可能 (unprintable) と見なすかにもかかわることになる。「変わり者のファイル名」セクションを参照していただきたい。

国際化されたメッセージで使用するロケールを決める。環境変数 `POSIXLY_CORRECT' が設定されている場合でも、やはりこの変数によって、アクション -ok が出したプロンプトに対する応答をどう解釈するかが決まってくる。

国際化メッセージ・カタログを置く場所を決める。

-exec, -execdir, -ok, -okdir によって呼び出される実行ファイルを捜すために検索するディレクトリに影響する。

-ls や -fls が使用するブロックサイズを決める。POSIXLY_CORRECT が設定されているときは、1 ブロック 512 バイト、設定されていないときは、1 ブロック 1024 バイトである。
また、この変数を設定すると、警告メッセージを出さないのがデフォルトになる (すなわち、 -nowarn になるわけだ)。なぜならば、POSIX の規定では、-ok の出すプロンプトを除いて、標準エラーに出力されるメッセージは、すべて問題が起きたことを知らせるものであり、 そのときの終了ステータスは 0 以外でなければならないからである。
POSIXLY_CORRECT が設定されていない場合は、+zzz が許可属性を表すシンボルとしてそれ自体有効な表現であるときを除き、-perm +zzz は -perm /zzz とまったく同じように扱われる (訳注: 現在では、 POSIXLY_CORRECT が設定されていない場合も、-perm +mode の書式はサポートされていない。検査 -perm の説明を参照)。POSIXLY_CORRECT が設定されている場合は、許可属性の前に '+' を取る形式は、エラーとして処理される (訳注: もちろん、+zzz がそれ自体有効なシンボル表現であるときは除く。たとえば、-perm +u+x といったものがそういう表現である。これは、-perm 0111 という「ぴったり一致する」表現と等価になる)。
POSIXLY_CORRECT が設定されていると、アクション -ok が出すプロンプトに対するユーザの応答を解釈する際に、find の持つメッセージ翻訳ではなく、システムのメッセージ・カタログが参照される。

タイムゾーンに影響する。タイムゾーンは、-printf や -fprintf の日時に関係する一部の書式指定子で使用される。

用例

find /tmp -name core -type f -print | xargs /bin/rm -f

/tmp ディレクトリ以下に core という名前のファイルを捜して、それを消去する。 ファイル名 (パスを含む) の中に改行、シングルクォート、ダブルクォート、 空白などを含むものがあると、正しく動作しないので、注意すること。

find /tmp -name core -type f -print0 | xargs -0 /bin/rm -f


/tmp ディレクトリ以下に core という名前のファイルを捜して、それを消去する。 ファイル名の処理に当たっては、ファイルやディレクトリの名前にシングルクォート、ダブルクォート、空白、改行などが含まれていても、適切に扱われるようにしている。 検査 -name を -type の前に置いているのは、すべてのファイルに対して stat(2) システムコールを行う無駄を省くためである。

find . -type f -exec file '{}' \;
カレントディレクトリ以下のあらゆるファイルに対して file コマンドを実行する。 波カッコをシングルクォートで囲んでいることに注目していただきたい。 シェルスクリプトのブロック区切り記号として解釈されないようにするためである。 同様に、セミコロンもバックスラッシュを使って保護している。 こちらにもシングルクォートを使用してもよい。 

find / \( -perm -4000 -fprintf /root/suid.txt '%#m %u %p\n' \) , \
\( -size +100M -fprintf /root/big.txt '%-10s %p\n' \)
全ファイルシステムを一回だけ探索して、setuid ビットの立っているファイルやディレクトリのリストを /root/suid.txt に、サイズの大きいファイルのリストを /root/big.txt に出力する。 

find $HOME -mtime 0
ここ 24 時間の内に内容が更新されたファイルをホームディレクトリ以下で検索する。 このコマンドがそういう動作になるのは、それぞれのファイルが最後に更新されてから現在までの経過時間が、24 時間で割られて、余りは捨てられるからである。 そこで、ファイルが -mtime 0 にマッチするためには、過去 24 時間未満の期間内に内容が更新されていなければならないことになる。 

find /sbin /usr/sbin -executable \! -readable -print
実行可能でありながら、読み出し不可能なファイルを捜す。 

find . -perm 664
ファイルの所有者とグループは読むことも書くことも可能だが、他のユーザは読み出しのみ可能で書き込みはできないファイルを捜す。 そうした条件を満たすものの、他の許可属性ビットも立っているような (たとえば、そのファイルを実行できる人がいるような) ファイルは、この式にマッチしない。 

find . -perm -664
ファイルの所有者とグループは読むことも書くことも可能であり、他のユーザも読むことが可能であるようなファイルを捜す。 それ以外の許可属性ビットについては (たとえば、実行許可ビット)、立っていてもいなくてもかまわない。この条件は、たとえば、 0777 のモードを持つファイルにもマッチすることになる。 

find . -perm /222
書き込める人のいるファイルを捜す (書き込めるのは、ファイルの所有者でも、グループでも、他の一般ユーザでもよい)。 

find . -perm /220
find . -perm /u+w,g+w
find . -perm /u=w,g=w
上記のコマンドは三つとも同じ動作をする。最初のものは、ファイルの許可属性を 8 進数で表し、後の二つは、シンボルによる表現形式を使っている。 こうしたコマンドはどれも、ファイルの所有者やグループが書き込み可能なファイルを捜す。 所有者とグループの両方が書き込み可能な場合しか、マッチしないわけではない。 どちらか片方だけでも十分である。 

find . -perm -220
find . -perm -g+w,u+w
この二つのコマンドは同じ動作をする。すなわち、ファイルの所有者とグループの両方が書き込み可能なファイルを捜す。 

find . -perm -444 -perm /222 \! -perm /111
find . -perm -a+r -perm /a+w \! -perm /a+x
この二つのコマンドは両方とも次のような条件のファイルを捜す。 その条件とは、誰にでも読み出すことが可能で (-perm -444 や -perm -a+r がそれにに当たる)、書き込み許可ビットが少なくとも一つは立っているが (-perm /222 や -perm /a+w)、誰にも実行することはできない (! -perm /111 や ! -perm /a+x) というものである。 

cd /source-dir
find . -name .snapshot -prune -o \( \! -name '*~' -print0 \)|
cpio -pmd0 /dest-dir
このコマンドは /source-dir の中身を /dest-dir にコピーするが、 その際 .snapshot という名前のファイルやディレクトリ (及び、そのディレクトリ内にあるもの) を除外している。 さらにこのコマンドは、名前の末尾に ~ が付くファイルやディレクトリも除外するが、 そうしたディレクトリの中身については除外の対象にしない。 -prune -o \( ... -print0 \) という構文はかなりよく利用される。 ここで肝腎なのは、-prune の前にある式がマッチする項目は、find の探索の対象から -prune によって取り除かれる (訳注: pruned、枝刈りされる) ということである。 しかし、アクション -prune 自体は返り値として真を返すので、直後に続く -o によって、探索の対象から取り除かれなかったディレクトリに対してだけ -o の右辺の評価が行われることになる (探索の対象から取り除かれたディレクトリの中身は、処理の対象にすらならないのだから、そうしたものはもう関係がない)。 -o の右辺の式をカッコで囲んでいるのは、見やすくするためにすぎない。 アクション -print0 が行われるのは、 -prune が適用されなかった項目のみであることを強調しているだけだ。 述語間のデフォルトの結合は and であり、and の結合は -o よりも強いから、 カッコがあってもデフォルトの動作と同じなのだが、カッコを使うと、何をやっているかがわかりやすくなる。 

find repo/ \( -exec test -d {}/.svn \; -or \
-exec test -d {}/.git \; -or -exec test -d {}/CVS \; \) \
-print -prune

以下のようなプロジェクトのディレクトリとそれに関連する SCM (ソースコード管理システム) の管理用ディレクトリがある場合に、プロジェクトのルートを効率的に検索する。

repo/project1/CVS
repo/gnu/project2/.svn
repo/gnu/project3/.svn
repo/gnu/project3/src/.svn
repo/project4/.git
この例では、-prune を使うことによって、すでにプロジェクトのルートであることがわかったディレクトリ以下で不必要な探索をしないですませている (たとえば、project3/src は探索しないが、それは project3/.svn がすでに見つかっているからだ)。それでいて、同格のディレクトリ (たとえば、 project2 と project3) はきちんと見つかるようにしている。 (訳注: この例の場合、カッコは必要である。and の結合は or よりも強いので。)

終了ステータス

find は、すべてのファイルを問題なく処理できれば、ステータス 0 で終了する。 エラーが起きた場合の終了ステータスは、1 以上である。 ここではあえてごく大雑把な言い方をしているが、返り値が 0 以外だった場合は、find が出した結果を正しいと思い込まない方がよいだろう。

エラーが起きた場合、find は、指定されたすべての動作を完了せず、 その場で終了してしまうことがある。その場合は、たとえば、探索開始点のあるものが調査されなかったり、 -exec ... {} + や -execdir ... {} + で呼び出されることになっているプログラムに実行されないものが生じたりするかもしれない。

関連項目

locate(1), locatedb(5), updatedb(1), xargs(1), chmod(1), fnmatch(3), regex(7), stat(2), lstat(2), ls(1), printf(3), strftime(3), ctime(3)

find については、充実した関連文書が Texinfo マニュアルの形で保守されている。 info と find プログラムが、御使用のサイトできちんとインストールされているならば、 info find とコマンドを打ち込むことで、詳細なマニュアルが読めるはずだ。 (訳注: info find だと、説明が途中からになるので、info "Finding files" と打ち込むことをお勧めする。)

履歴

findutils-4.2.2 以来、ファイル名のパターンに使われるシェルのメタ文字 (`*', `?', `[]' など) は、先頭の `.' にマッチする。 これは、IEEE POSIX interpretation 126 がそう要求しているからである。

findutils-4.3.3 以来、-perm /000 は、どんなファイルにもマッチしないではなく、すべてのファイルにマッチする、になっている。

ナノ秒まで表現するタイムスタンプは findutils-4.3.3 で実装された。

findutils-4.3.11 以来、アクション -delete は、実行に失敗すると、 find の終了ステータスを 0 以外の値にする。とは言え、find がその場で即座に終了してしまうわけではない。以前のバージョンでは、-delete が実行に失敗しても、find の終了ステータスは影響を受けなかった。

Feature Added in Also occurs in
-newerXY 4.3.3 BSD
-D 4.3.1
-O 4.3.1
-readable 4.3.0
-writable 4.3.0
-executable 4.3.0
-regextype 4.2.24
-exec ... + 4.2.12 POSIX
-execdir 4.2.12 BSD
-okdir 4.2.12
-samefile 4.2.11
-H 4.2.5 POSIX
-L 4.2.5 POSIX
-P 4.2.5 BSD
-delete 4.2.3
-quit 4.2.3
-d 4.2.3 BSD
-wholename 4.2.0
-iwholename 4.2.0
-ignore_readdir_race 4.2.0
-fls 4.0
-ilname 3.8
-iname 3.8
-ipath 3.8
-iregex 3.8

-perm +MODE という書き方は、findutils-4.5.12 で廃止された。代わりに、-perm /MODE を使用すること。 +MODE という記法は、2005 年にリリースされた findutils-4.2.21 以来非推奨になっていた。

バグにあらず

$ find . -name *.c -print
find: paths must precede expression
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]

こうしたエラーが起きる原因は、 *.c がシェルによって展開されて、find が実際に受け取るコマンドラインが、たとえば次のようなものになってしまうからである。

find . -name bigram.c code.c frcode.c locate.c -print

当然ながら、こんなコマンドがうまく動くわけがない。書き方を改めて、パターンを引用符で囲むか、ワイルドカードをエスケープするべきだ。

$ find . -name '*.c' -print
$ find . -name \*.c -print

バグ

POSIX 規格が find について規定している動作には、セキュリティ上の問題があるが、 それはその動作に内在する問題なので、修正することができない。一例を挙げると、アクション -exec は本質的に安全ではない。だから、-execdir の方を使うべきなのだ。より詳しい情報については、Finding Files をご覧いただきたい。

環境変数 LC_COLLATE はアクション -ok にまったく影響を及ぼさない (訳注: 環境変数 LC_COLLATE の説明では 「この変数はアクション -ok に対する応答の解釈にも影響を及ぼす」と述べている)。

バグ報告の最善の方法は、http://savannah.gnu.org/bugs/?group=findutils にある書式を使用することである。そうすれば、問題解決の進行状態を追うことができるからだ。 find(1) や findutils パッケージ全般についてのその他のご意見は、 bug-findutils メーリングリストにお出しになればよい。 メーリングリストに参加するには、bug-findutils-request@gnu.org 宛に E メールを送っていただきたい。

翻訳について

この翻訳は findutils-4.6.0 所収の find.1 の翻訳である。 お手元の findutils は、もっと新しいバージョン、たとえば 4.7.0-git になっているかもしれない。だが、4.7.0 は開発中の版なので、manpage も変化し続けており、現時点で最新の 4.7.0 のマニュアルを翻訳しても、お手元の英語マニュアルとは内容が微妙に違うかもしれないのだ。 バージョンが同じ 4.7.0 なのに、それでは紛らわしい。そこで、あえて現在の安定版、4.6.0 のマニュアルを底本にした。

4.6.0 と最近の 4.7.0-git との大きな相違は、-D のデバックオプションに exec と search が増えていることと、検査 -type や -xtype で "-type f,l" などと、複数のファイルタイプをコンマで区切って指定できるようになったことくらいである。

なお、バージョン 4.4.2 までの翻訳では、述語の Test (-mtime, -name, -type など) を「判別式」と訳してきたが、今回は素直に「検査」と訳すことにした。同じものである。 「条件、条件式、検索式、検索条件、テスト」などの訳語もあったと思う。 これまでの「判別式」という訳語に慣れた方には、ご迷惑だったかもしれない。 お許しいただきたい。(2018/03/03)