位置オプション

位置オプションは、 常に true を返します。 位置オプションは、 この後ろにあるテストに対してのみ影響を及ぼします。

-daystart

時間の計測を、 24 時間前からではなく、 本日の始まりからとします (対象は -amin, -atime, -cmin, -ctime, -mmin, -mtime です)。 このオプションの指定が有効になるのは、 コマンドライン上でこれよりも後ろに記述されたテストに対してのみです。

-follow

非推奨とされています。 代わりに -L オプションを使ってください。 これはシンボリックリンクをたどます。 -noleaf の指定を暗に含みます。 -follow オプションが影響を及ぼすのは、 コマンドライン上で、 これよりも後ろに指定されたテストに対してのみです。 -H あるいは -L オプションの指定がなければ、 -follow オプションが記述されると、 述語表現 -newer の動作は変わります。 -newer の引数として指定されたファイルが、 シンボリックリンクであった場合は、 そのリンク先が参照されます。 -newerXY, -anewer, -cnewer についても同様です。 また、 述語表現の -type も、 シンボリックリンクそのものではなく、 シンボリックリンク先のファイルタイプに一致するようになります。 -follow を指定すると、 述語表現 -lname と -ilname は、 必ず false を返します。

-regextype type

コマンドライン上で、 この後に記述されるテスト -regex と -iregex に対して、 解釈する正規表現文法を変更します。 正規表現の種類には何があるかについては、 -regextype help を実行して確認してください。 Texinfo 文書 (「関連項目」参照) では、 各種正規表現の意味や違いについて説明しています。

-warn, -nowarn

警告メッセージの表示、非表示を切り替えます。 この警告は、 コマンドラインの使用法に関するものだけを対象とします。 逆に find のディレクトリ検索時における処理状況に関するものは、 対象としません。 デフォルトの動作は、 標準入力が tty であれば -warn になり、 そうでなければ -nowarn になります。 コマンドラインの使用法に関する警告メッセージが出力された場合であっても、 find の終了ステータスには影響しません。 環境変数 POSIXLY_CORRECT が設定された状態で、 -warn が指定されると、 警告が発生したとしても、 どの警告を出すのかは未定です。

グローバルオプション

グローバルオプションは、必ず true を返します。 グローバルオプションは、 コマンドライン上で、 これよりも前にあるテストに対しても影響を及ぼします。 混乱を避けるために、 コマンドライン上でのグローバルオプションの指定は、 検索開始ポイントのリストの後ろで、 テスト、位置オプション、 アクションの直前に指定してください。 グローバルオプションを、 それとは別の場所で指定すると、 find は、 混乱する可能性があることを示す警告メッセージを出力します。

グローバルオプションの指定位置は、 検索開始ポイントのリストより後ろです。 このため -L とは異なる種類のものです。 たとえば以下のとおりです。

-d

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

-depth

ディレクトリそのものより前に、 ディレクトリの中を処理します。 アクション -delete には -depth オプションが暗に含まれています。

-files0-from file

検索開始ポイントを、 コマンドラインから指定されたものを使わずに、 file から読み込みます。 コマンドラインからの引数として検索開始ポイントを指定することには、 一定の制約がありました。 つまりファイルの指定数に上限があったことです。 またオプション名とかぶるようなファイル名の場合に、 見誤ってしまうことがありました。 このオプションを使うと、 find に指定する検索開始ポイントを、 安全にまた任意の数だけ受け渡すことができます。

このオプションを用いることと、 コマンドラインから検索開始ポイントを受け渡すことは、 互いに排他的な関係にあります。 つまり両方を同時に用いることはできません。

引数 file は必須です。 検索開始ポイントの一覧を 標準入力 ストリームからとることは可能であり、 たとえばパイプを使って受け渡すことができます。 その場合、 アクション -ok と -okdir は用いることができません。 これらはユーザーからの入力確認を行うものであるため、 標準入力 からの読み込みとは、 明らかに相容れないものになるからです。

file 内の検索開始ポイントは、 ASCII NUL 文字によって区切ります。 2 つの連続した NUL 文字、 つまり検索開始ポイントのファイル名の長さがゼロであるものは、 指定することができません。 その場合はエラーメッセージが出力されて、最後にゼロ以外の終了コードが返されます。

指定された file が空の場合、 find は検索開始ポイントがないものとして処理をするため、 プログラム引数を解析した後に、 すぐに終了します。 これは、 パス引数が受け渡されなかった場合に、 find の標準的な呼び出しを行えば、 カレントディレクトリを検索開始ポイントとする動作とは異なることになります。

検索開始ポイントからの処理は、 それ以外の点では通常どおり行われます。 つまり find は特に指示がない限りは、 サブディレクトリを再帰的に処理します。 検索開始ポイントだけを処理するには、 さらに -maxdepth 0 を指定することができます。

さらに注意点です。 入力ファイル内に所定のファイルが複数回記述されていた場合、 それが複数回検索されることになるかどうかは不定です。 find の処理中に file が変更された場合も、 同様に不定です。 また find が終了する際の、その指定された file 内の検索位置も、 終了方法が -quit であるか別の方法であるかを問わず、 不定となります。 ここで "不定" と言っているのは、 動作するしないは分からず、何か特定の処理がなされるかもしれないということであり、 その動作は、 プラットフォームによって変わるかもしれないし、 findutils のリリースによって変わるかもしれないということです。

-help, --help

find のコマンドラインの使用方法の概要を表示して終了します。

-ignore_readdir_race

通常 find は、 ファイル情報の取得に失敗したときには、 エラーメッセージを出力します。 このオプションを指定した場合、 ディレクトリからファイル名を読み込んだときと、 ファイル情報を取得しようとしたときの間で、 ファイルが削除されてしまっていても、 エラーは表示されません。 この動作は、 コマンドライン上から指定されるファイルやディレクトリに対しても適用されます。 このオプションは、 コマンドラインから読み込みを行う段階で有効となるので、 ファイルシステムの一部に対して、 このオプションをオンとし、 残りの部分はオフとするような指定はできません。 (これを実現しなければならない場合は、 find コマンドを 2 つ実行することが必要です。1 つは本オプションをオンにして、 もう 1 つはオフにして実行します。)

さらに、 -ignore_readdir_race オプションを指定した find の実行では、 親ディレクトリを読み込んだ後に、 対象ファイルが消失している状況が発生した場合、 -delete アクションからのエラーも無視します。 その場合には、 診断エラーは出力されず、 -delete アクションからの返り値も true になります。

-maxdepth levels

検索開始ポイントから最大で、 levels で示される階層数のディレクトリまで検索します (levels は負ではない整数です)。 -maxdepth 0 を指定すると、 テストやアクションの対象は、 検索開始ポイントだけになります。

-mindepth levels

検索開始ポイントから levels で示される階層数のディレクトリに至るまでは、 テストやアクションを適用しません (levels は負ではない整数です。)。 -mindepth 1 を指定すると、 検索開始ポイントを除いたファイルを、 すべて処理することになります。

-mount

ファイルシステムが異なる場合は、 ディレクトリを検索しません。 これは -xdev の別名であり、 バージョンが異なる find との互換性のために設けられています。

-noignore_readdir_race

-ignore_readdir_race の効果を無効にします。

-noleaf

ディレクトリに含まれるサブディレクトリ数が、 ハードリンク数よりも 2 つ少ない、 とする想定のもとでの最適化を無効にします。 このオプションが必要になるのは、 Unix のディレクトリとリンクに関する慣例に従っていないファイルシステム、 たとえば CD-ROM、 MS-DOS ファイルシステム、 AFS ボリュームマウントポイントを検索する場合です。 通常の Unix ファイルシステムにおいては、 各ディレクトリに最低でも 2 つのハードリンクがあります。 ディレクトリ名そのものと、 `.' エントリです。 そしてサブディレクトリがある場合に、 そのサブディレクトリには、 親ディレクトリにリンクする `..' というエントリがあります。 そこで find がディレクトリを調べる際に、 ディレクトリへのリンク数よりも 2 つ分だけ少ないサブディレクトリを調べた後であれば、 ディレクトリ内の残りのエントリは、 ディレクトリではない (ディレクトリツリー内の「葉」(leaf) ファイルである) ことが決定します。 ファイル名を調べるだけで十分であれば、 ファイル情報を調べる必要がなくなるので、 これを利用すれば、 検索速度が明らかに向上します。

-version, --version

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

-xdev

異なるファイルシステムのディレクトリを検索しません。

テスト (test)

テストの中には、 -newerXY や -samefile のように、 その時点で対象となっているファイルと、 コマンドラインから指定する参照ファイル (reference file) との間で、 比較を行うものがあります。 そのようなテストが指定された際に、 参照ファイルに対する解釈は、 -H, -L, -P といったオプションや、 先行する -follow の存在によって決定します。 ただし、 参照ファイルが調べられるのは、 コマンドラインが解析されるときの 1 回だけです。 参照ファイルが調べられなかった場合 (たとえば、 stat(2) システムコールに失敗した場合)、 エラーメッセージが出力されて、 find は 0 以外のステータスを返して終了します。

数値引数である n は、 以下のテスト、 -amin, -mtime, -gid, -inum, -links, -size, -uid, -used において指定できます。 そして以下のような指定方法があります。

+n

n より大きい。

-n

n より小さい。

n

n にちょうど等しい。

サポートされているテスト:

-amin n

ファイルの最終アクセス時間が、 n 分前と比較して、 それよりも前か後かちょうど同じかをテストします。

-anewer reference

現在ファイルの最終アクセス時間が、 reference (参照ファイル) の最終更新時間よりも、 新しいかどうかをテストします。 引数 reference がシンボリックリンクであり、 -H や -L オプションが有効になっている場合は、 リンク先ファイルの最終更新時間が常に利用されます。

-atime n

ファイルの最終アクセス時間が、 n*24 時間前と比較して、 それよりも前か後かちょうど同じかをテストします。 ファイルの最終アクセス時間が、 24 時間の何倍であるかを割り算して計算する際に、 端数は無視されます。 したがって、 -atime +1 に一致するためには、 ファイルは少なくとも 2 日前にアクセスされていなければなりません。

-cmin n

ファイルステータスの最終変更時間が、 n 分前と比較して、 それよりも前か後かちょうど同じかをテストします。

-cnewer reference

現在ファイルの最終ステータス変更時間が、 reference (参照ファイル) の最終更新時間よりも、 新しいかどうかをテストします。 引数 reference がシンボリックリンクであり、 -H や -L オプションが有効になっている場合は、 リンク先ファイルの最終更新時間が常に利用されます。

-ctime n

ファイルステータスの最終変更時間が、 n*24 時間前と比較して、 それよりも前か後かちょうど同じかをテストします。ファイルステータスの更新時間の解釈にあたって、丸め処理がどのように影響するかについては、 -atime の説明を参照してください。

-empty

ファイルが空であって、 通常のファイルかディレクトリであるかどうかをテストします。

-executable

実行可能なファイルか、 あるいは、 現在のユーザーが (ファイル名解決の観点で) 検索可能なディレクトリであるかどうかをテストします。 このテストは、 アクセスコントロールリスト (access control list; ACL) や、 この他のパーミッション機能を考慮します。 ちなみに、 テスト -perm では無視されます。 本テストは、 システムコール access(2) を利用するので、 NFS サーバーが UID マッピング (つまり root squash) を行っている場合に、 適切に動作しない場合があります。 多くのシステムでは、 クライアントのカーネルにおいて access(2) を実装しているため、 サーバー側にある UID マッピング情報を利用できないからです。 このテストは、 access(2) システムコールの結果だけに基づいているため、 このテストが true となったファイルが、 実際に実行できるかどうかの保証はありません。

-false

必ず false を返します。

-fstype type

ファイルが存在するファイルシステムが、 type かどうかをテストします。 いろいろな Unix システムに対して、 有効なファイルシステムは変わります。 Unix などの各種システムにおいて、 許容されるファイルシステムタイプを、 その一部だけあげてみると、 ufs, 4.2, 4.3, nfs, tmp, mfs, S51K, S52K といったものです。 -printf のディレクティブ %F を使えば、 現在のファイルシステムタイプを確認することができます。

-gid n

ファイルのグループ ID 番号が、 n と比較して、 それよりも小さいか大きいかちょうど同じかをテストします。

-group gname

ファイルの属するグループが gname かどうかをテストします (グループ ID 番号による指定も可)。

-ilname pattern

-lname と同様ですが、 大文字小文字は区別しません。 -L または -follow オプションが有効な場合、 シンボリックリンクが切れていない限り、 このテストは false を返します。

-iname pattern

-name と同様ですが、 大文字小文字は区別しません。 たとえば、 パターン `fo*' や `F??' は、 `Foo', `FOO', `foo', `fOo' などのファイル名に一致します。 また、 パターン `*foo*' は、 `.foobar' というファイルにも一致します。

-inum n

ファイルの i ノード番号が、 n と比較して、 それよりも小さいか大きいかちょうど同じかをテストします。 普通はこれよりも、 -samefile を使った方が簡単です。

-ipath pattern

-path と同様です。 ただし大文字小文字を区別しません。

-iregex pattern

-regex と同様です。 ただし大文字小文字を区別しません。

-iwholename pattern

-ipath を参照してください。 この別名は、 -ipath よりも移植性に劣ります。

-links n

ファイルが持つハードリンクの数が、 n と比較して、 小さいか大きいかちょうど同じかをテストします。

-lname pattern

ファイルがシンボリックリンクであって、 その内容がシェルパターン pattern に一致するかどうかをテストします。 メタ文字は、 `/' や `.' を特別扱いしません。 -L または -follow オプションが有効な場合には、 シンボリックリンクが切れていない限り、 このテストは false を返します。

-mmin n

ファイルの最終更新時間が、 n 分前と比較して、 それよりも前か後かちょうど同じかをテストします。

-mtime n

ファイルの最終更新時間が、 n*24 時間前と比較して、 それよりも前か後かちょうど同じかをテストします。 何日前かを計算する際、 時間差を 24 時間で割った結果を丸めるため、 ファイル更新時間の解釈にあたって、 その処理がどのように影響するかについては、 -atime の説明を参照してください。

-name pattern

ファイルのベース名 (パス名から、 先行するディレクトリを取り除いたもの) が、 シェルのパターン pattern に一致するかどうかをテストします。 先行するディレクトリを取り除いているので、 -name を使って一致の確認を行うファイル名には、 スラッシュが含まれないものとして扱われます。 つまり `-name a/b' としても、 一致するものはありません (その場合は、 おそらく -path を用いる必要があります)。 これを行ってしまった場合、 環境変数 POSIXLY_CORRECT が設定されていない限りは、 警告メッセージが出力されます。 メタ文字 (`*', `?', `[]') は、 ベース名の先頭にある `.' に一致します (これは findutils-4.2.2 から変更されました。以降のセクション「規格への準拠」を参照してください)。 1 つのディレクトリとそこに含まれるファイルを無視したい場合は、 ディレクトリツリー内の全ファイルを確認するのではなく、 -prune を使います。-prune の説明において、 例を説明しているので参照してください。 波カッコ ('{}') は、 特別な文字としては扱われません。 bash などのシェルにおいては、 シェルパターン内の波カッコに特別な意味を持つものがありますが、 この点は異なります。 ファイル名のマッチングは、 fnmatch(3) ライブラリ関数を用いて行われます。 シェルによってパターンが展開されないように、 パターンはクォートで囲むことを忘れないでください。

-newer reference

対象ファイルの最終更新時間が、 reference ファイルの最終更新時間よりも、 最新であるかどうかをテストします。 reference がシンボリックリンクであって、 -H または -L オプションが有効である場合は、 リンク先ファイルの更新時間が用いられます。

-newerXY reference

対象ファイルのタイムスタンプ X が、 reference ファイルのタイムスタンプ Y より、 新しいかどうかをテストします。 X と Y の位置に記述する文字は、 以下の文字とします。

a	reference ファイルのアクセス時間
B	reference ファイルの生成時間
c	reference ファイルの i ノードステータスが変更された時間
m	reference ファイルの内容更新時間
t	reference に直接時間表現が書かれたとして解釈

組み合わせによっては、 無効になるものも発生します。 たとえば、 X に t を指定しても無効です。 またシステムによっては、 特定の組み合わせを実装していない場合があります。 たとえば B は、 すべてのシステムでサポートされているわけではありません。 指定された XY の組み合わせが、 無効や未サポートの場合は、 致命的エラーが発生します。 時間表現は、 GNU date における -d オプションに対する引数と同様のものとして解釈されます。 参照ファイルの生成時間を使用しようとて、 その生成時間が決定できなかった場合は、 致命的エラーになります。 また、 対象ファイルの生成時間を参照するテストを用いた際に、 生成時間が不明な場合は、 そのテストは失敗します。

-nogroup

ファイルのグループ ID 番号が、 システムに存在していないことをテストします。

-nouser

ファイルのユーザー ID 番号が、 システムに存在しないことをテストします。

-path pattern

ファイル名が、 シェルのパターン pattern に一致するかどうかをテストします。 メタ文字は、 `/' や `.' を特別扱いしません。 したがってたとえば、

find . -path "./sr*sc"

は、 ./src/misc というディレクトリ (それが存在している場合) の内容を表示します。 ディレクトリツリー全体を対象としないのであれば、 ツリー内の各ファイルを確認していくのではなく、 -prune を用います。 パターン一致を確認するようなテストは、 ファイル名すべてに対して適用されます。 つまりそのファイル名は、 コマンドライン上から指定された検索開始点から始まる、 検索対象すべてです。 このパターンにおいて、 絶対パスを指定するなら、 検索開始点も絶対パスでなければ意味がありません。 つまり以下のようなコマンドでは、 どのファイルも一致しません。

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

find が -path の引数と比較するのは、 その時点で対象としているファイルのディレクトリとベース名を連結した文字列です。 その文字列の末尾がスラッシュになることはないため、 -path の引数の末尾にスラッシュを指定すると、 何にも一致しないことになります。 (ただし、 コマンドラインで指定された検索開始ポイントには、 おそらく一致します)。 述語表現 -path は、 HP-UX の find でもサポートされていて、 POSIX 2008 規格に存在します。

-perm mode

ファイルの許可属性が mode (8 進数表現またはシンボル表現) に一致するかどうかをテストします。 mode 指定のこの形式では、 完全一致が求められるので、 この形式をシンボリックモードで使う場合には、 モード文字列の指定が多少複雑になるかもしれません。 たとえば `-perm g=w' は、 許可属性が 0020 のファイルにのみ一致します (つまり、 グループの書き込み権限のみを設定します)。 おそらく、 `/' や `-' を用いる形式を必要とすることがあります。 たとえば、 `-perm -g=w' とすれば、 グループの書き込み許可があるファイルに一致します。 具体例については「例」セクションを参照してください。

-perm -mode

mode で指定した許可属性ビットすべてが、 対象ファイルのものに一致するかどうかをテストします。 この形式でも、 シンボリックモード指定が可能です。 このモードは、 ごく普通に用いたくなるはずです。 シンボリックモードでは、 `u'、 `g'、 `o' を用いる必要があります。 具体例については「例」セクションを参照してください。

-perm /mode

mode で指定した許可属性ビットの一部が、 対象ファイルのものに一致するかどうかをテストします。 この形式でも、 シンボリックモード指定が可能です。 シンボリックモードでは、 `u'、 `g'、 `o' を用いる必要があります。 具体例については「例」セクションを参照してください。 なお、 mode の許可属性ビットが何も設定されていない場合、 このテストは、 どんなファイルにも一致します (この動作は、 -perm -000 と一貫性を持たせるためです)。

-perm +mode

この書式は、 もうサポートされていません (2005 年以来、 非推奨となっています)。 代わりに -perm /mode を用いてください。

-readable

現在のユーザーによって読み込み可能なファイルであるかどうかをテストします。 このテストは、 アクセスコントロールリスト (access control list; ACL) や、 その他のパーミッション機能を考慮します。 ちなみに、 テスト -perm では無視されます。 本テストは、 システムコール access(2) を利用するので、 NFS サーバーが UID マッピング (つまり root squash) を行っている場合に、 適切に動作しない場合があります。 多くのシステムでは、 クライアントのカーネルにおいて access(2) を実装しているため、 サーバー側にある UID マッピング情報を利用できないからです。

-regex pattern

ファイル名が正規表現 pattern に一致するかどうかをテストします。 この処理は、 パス全体への一致を確認するものであって、 ファイル検索ではありません。 したがってたとえば、 `./fubar3' ファイルに一致する正規表現として、 `.*bar.' や `.*b.*3' は利用できますが、 `f.*r3' は利用できません。 find が扱う正規表現のデフォルトは、 Emacs 正規表現です ('.' が改行に一致する点は除きます)。 これは、 -regextype オプションを用いて変更することができます。

-samefile name

対象ファイルが、 name と同じ i ノードを参照しているかどうかをテストします。 -L が有効であれば、 シンボリックリンクを対象とすることができます。

-size n[cwbkMG]

ファイルが n 単位分の容量と比較して、 それよりも小さいか大きいかちょうど同じかをテストします。 ここでは丸め処理が行われます。 以下のサフィックスが利用できます。

サイズというのは単純に、 システムコールの lstat (あるいは stat) に含まれている struct stat の メンバー st_size のことであり、 上に示すようにして切り上げられます。言い換えると、 その結果は ls -l で得られるものと一致します。-printf における `%k' と `%b' の書式指定子は、 スパースファイルに対して、 異なる扱いをする点に注意してください。 サフィックス `b' は、 常に 512 バイトブロックを表していて、 1024 バイトブロックを表すことはありません。 この点は、 -ls の動作とは異なるところです。

プレフィックスの + と - は、 ごく普通に、 それより上、 それより下、 を表します。 したがって、 n とちょうど同じ数には一致しません。 サイズとは、 次の数単位に向けて切り上げられることに注意してください。 つまり -size -1M というのは、 -size -1048576c と同じではありません。 前者は、 空のファイルにしか一致しません。 また後者は、 バイトサイズが 0 から 1,048,575 までのファイルに一致します。

-true

常に true です。

-type c

ファイルタイプが c であるかどうかをテストします。

一度に複数のファイルタイプを検索したい場合は、 タイプを表す英字を、 カンマ `,' で区切ったリストで指定します。 (GNU 拡張)

-uid n

ファイル所有者のユーザー ID 番号が、 n と比較して、 それよりも小さいか大きいかちょうど同じかをテストします。

-used n

ファイルのステータスが変更されてから、 ファイルにアクセスした最終時間が、 n 日間と比較して、 小さいか大きいかちょうど同じかをテストします。

-user uname

ファイルの所有者が、 uname というユーザーであるかどうかをテストします (ユーザー ID 番号による指定も可)。

-wholename pattern

-path を参照してください。 この別名は、 -path よりも移植性に劣ります。

-writable

現在のユーザーによって書き込み可能なファイルであるかどうかをテストします。 このテストは、 アクセスコントロールリスト (access control list; ACL) や、 その他のパーミッション機能を考慮します。 ちなみに、 テスト -perm では無視されます。 本テストは、 システムコール access(2) を利用するので、 NFS サーバーが UID マッピング (つまり root squash) を行っている場合に、 適切に動作しない場合があります。 多くのシステムでは、 クライアントのカーネルにおいて access(2) を実装しているため、 サーバー側にある UID マッピング情報を利用できないからです。

-xtype c

対象ファイルがシンボリックリンクでなければ、 -type と同様です。 シンボリックリンクのときは、 以下のように動作します。 -H や -P オプションの指定時は、 リンク先がタイプ c のファイルであれば、 true を返します。 -L オプションの指定時は、 c が `l' ならば true を返します。 言い換えると、 シンボリックリンクに対して、 -xtype は、 -type がチェックしないファイルタイプをチェックします。

-context pattern

(SELinux 有効時のみ) 対象ファイルのセキュリティコンテキストが glob パターン pattern に一致するかどうかをテストします。

アクション

-delete

ファイルまたはディレクトリを削除します。 削除に成功すると true を返します。 削除に失敗した場合は、 エラーメッセージを表示して、　ゼロ以外の終了ステータスを返します (最終終了するときです)。

警告: find はコマンドラインを式として評価する点を忘れないでください。 したがって -delete を一番初めに記述すると、 それは find に対して、 検索開始ポイント以下のものをすべて削除させることになります。

コマンドラインから -delete オプションを指定すると、 自動的に -depth オプションがオンとなります。 一方で -depth は -prune を無効にするので、 -delete アクションは -prune と同時に用いることはできません。

ユーザーの中ではよく、 コマンドライン上において -delete の前に -print を指定して、 削除が実際にどのように行われるかをテストしようとします。 予期しない結果を起こさないためにも、 そのようなテストを行うときから、 -depth オプションを明示的に指定することを忘れないでください。

-delete アクションは、 ディレクトリが空でない場合には削除に失敗します。

-ignore_readdir_race オプションとともに、 このオプションを指定し、 さらに、 親ディレクトリを読み込んだ後に、 対象ファイルが消失している状況が発生した場合、 -delete アクションからのエラーは無視されます。 その場合には、 診断エラーは出力されず、 終了コードをゼロ以外には変えずに -delete アクションからの返り値も true になります。

-exec command ;

command を実行します。 command の返り値が 0 なら、 true を返します。 find のコマンドラインで、 これ以降に指定されている引数は、 `;' という引数が現れるまで、 すべてそのコマンドに対する引数とみなされます。 文字列 `{}' は、 コマンド引数内に現れるすべての箇所で、 対象ファイル名に置き換えられます。 find の他の実装においては、 引数の中で `{}' が単独で用いられていないと、 対象ファイル名に置き換えられないものがあります。 文字列 `{}' は、 シェルによって展開されないように、 どちらも `\' でエスケープするか、 クォートで囲む必要があります。 アクション -exec の具体例については、 「例」セクションを参照してください。 指定されたコマンドは、 一致したファイルごとに一回ずつ実行されます。 そのコマンドは、 find を実行したディレクトリにおいて実行されます。 そこで、 -exec アクションの実行にあたっては、 セキュリティの問題が避けられません。 したがって、 -exec の代わりに、 -execdir アクションを使用してください。

-exec command {} +

この形式の -exec アクションは、 対象ファイルに対して、 指定されたコマンド (command) を実行します。 各対象ファイルは、 コマンドラインの末尾に追加されながら、 コマンドラインが構成されるので、 指定コマンドの呼び出し回数は、 対象ファイル数よりも大幅に少なくて済みます。 コマンドラインが構成される処理方法は、 xargs の場合とほぼ同じです。 `{}' の記述は、 コマンドライン中に 1 度しか用いることはできず、 しかも最後に `+' を伴って、 コマンドラインの最終記述としなければなりません。 また、 シェルによって誤った解釈が行われないように、 (`\' を使って) エスケープするか、 全体をクォートで囲むことが必要です。 そのコマンドは、 find を実行したディレクトリにおいて実行されます。 '+' 形式を使った呼び出しにおいて、 終了ステータスにゼロでない値が返ってきたら、 find も、 終了ステータスにゼロ以外を返します。 find においてエラーが発生すると、 その場ですぐに終了する場合があります。 その際には、 残りのコマンドがまったく実行されないこともあります。 このため、 -exec my-command ... {} + -quit では、 my-command が実際には実行されない場合があります。 なおこの -exec の形式は、 必ず true を返します。

-execdir command ;

-execdir command {} +

-exec と同様ですが、 指定したコマンドは、 一致したファイルが存在するサブディレクトリ内で実行されます。 このサブディレクトリは、 普通は find を実行したディレクトリとは異なるはずです。 -exec と同じように、 find をシェルから呼び出す場合には {} をクォートでくくる必要があります。 この形式は、 コマンドを呼び出す方法として、 非常に安全なものです。 一致したファイルのパスを確定させる際に、 競合状態を避けることができるためです。 -exec アクションの場合と同様、 -execdir の `+' 形式の実行においても、 一致した複数ファイルを処理するようなコマンドラインが構成されます。 ただし、 指定された command の呼び出しは、 どの場合であっても、 必ず同一サブディレクトリ内にあるファイルだけを対象にして実行されます。 このオプションの利用にあたっては、 環境変数 PATH が、 `.' を参照していないようにする必要があります。 そうしていないと、 攻撃者が、 -execdir を実行するディレクトリ内に、 いかにも正しいファイルを置くだけで、 任意のコマンド実行を許してしまうことになります。 PATH 内のエントリに、 空のものや、 相対パスのディレクトリ名を含んでいる場合にも、 同じことが言えます。 '+' 形式を使った呼び出しにおいて、 終了ステータスにゼロでない値が返ってきたら、 find も、 終了ステータスにゼロ以外を返します。 find においてエラーが発生すると、 その場ですぐに終了する場合があります。 その際には、 残りのコマンドがまったく実行されないこともあります。 このアクションが返す値は、 + と ; のどちらの形式を使うかによって異なります。 -execdir command {} + は必ず true を返しますが、 -execdir command {} ; は、 command が 0 を返したときだけ、 true を返します。

-fls file

true を返します。 -ls と同様ですが、 -fprint のように、 file への出力を行います。 出力ファイルは、 この述語表現に一致するものがなくても、 必ず生成されます。 ファイル名に、 普通は使わない文字が含まれている場合の扱いについては、 「普通ではないファイル名」のセクションを参照してください。

-fprint file

true を返します。 パス付きのファイル名を、 ファイル file に出力します。　find の実行時に、 file が存在しなければ、 新たに生成されます。 すでに存在していたら、 元の中身は失われます。 ファイル名 /dev/stdout と /dev/stderr は特別に扱われます。 それぞれ、 標準出力、 標準エラー出力を意味します。 出力ファイルは、 この述語表現に一致するものがなくても、 必ず生成されます。 ファイル名に、 普通は使わない文字が含まれている場合の扱いについては、 「普通ではないファイル名」のセクションを参照してください。

-fprint0 file

true を返します。 -print0 と同様ですが、 -fprint のように、 file への出力を行います。 出力ファイルは、 この述語表現に一致するものがなくても、 必ず生成されます。 ファイル名に、 普通は使わない文字が含まれている場合の扱いについては、 「普通ではないファイル名」のセクションを参照してください。

-fprintf file format

true を返します。 -printf と同様ですが、 -fprint のように、 file への出力を行います。 出力ファイルは、 この述語表現に一致するものがなくても、 必ず生成されます。 ファイル名に、 普通は使わない文字が含まれている場合の扱いについては、 「普通ではないファイル名」のセクションを参照してください。

-ls

true を返します。 対象ファイルを、 ls -dils の書式で標準出力に出力します。 ブロック数は、 1 ブロックに 1 KB バイトです。　ただし、 環境変数 POSIXLY_CORRECT が設定されている場合は、 1 ブロック 512 バイトが使用されます。　ファイル名に、 普通は使わない文字が含まれている場合の扱いについては、 「普通ではないファイル名」のセクションを参照してください。

-ok command ;

-exec と同様ですが、 ユーザーへの問い合わせを行います。　ユーザーが同意すれば、 コマンドを実行します。 同意しなければ、 何もせずに false を返します。 コマンドが実行される際に、 標準入力はリダイレクトされて、 /dev/null になります。 このオプションは -files0-from オプションとともに指定することはできません。

プロンプトに対するユーザーの入力は、 肯定、 否定を表す一組の正規表現との一致確認が行われて、 同意したかどうかが決定します。 この正規表現は、 環境変数 POSIXLY_CORRECT が設定されていれば、 システムから取得されます。 環境変数が設定されていなければ、 find が持つメッセージ翻訳から取得されます。 システムに適切な定義が存在しなかった場合は、 find 自体が持つ定義が使用されます。 どの場合でも、 正規表現そのものの解釈は、 環境変数 LC_CTYPE (文字クラス) や LC_COLLATE (文字の範囲や等価クラス) の影響を受けます。

-okdir command ;

-execdir と同様ですが、 -ok と同じように、 ユーザーへの問い合わせを行ないます。 ユーザーが同意しなければ、 何もせずに false を返します。 コマンドが実行される際に、 標準入力はリダイレクトされて、 /dev/null になります。 このオプションは -files0-from オプションとともに指定することはできません。

-print

true を返します。 パス付きのファイル名と、 最後に改行文字をつけて、 標準出力に出力します。 find の出力を、 パイプを使って他のプログラムに受け渡している場合、 対象ファイル名に改行文字が含まれている可能性が、 少しでもあるなら、 -print ではなく、 -print0 アクションの使用を是非考えてください。 ファイル名に、 普通は使わない文字が含まれている場合の扱いについては、 「普通ではないファイル名」のセクションを参照してください。

-print0

true を返します。 パス付きのファイル名と、 最後にヌル文字をつけて、 標準出力に出力します (-print が改行文字をつけるのとは異なります)。 このアクションを使えば、 find の出力を処理するプログラムが、 改行文字やホワイトスペースを含むファイル名を、 正しく解釈できるようになります。 このアクションは、 xargs の -0 オプションに対応します。

-printf format

true を返します。 これは標準出力に format を出力します。 format 内の `\' によるエスケープや、 `%' に始まるディレクティブを解釈します。 フィールドの幅や精度は、 C 言語の printf(3) 関数と同じ方法で指定することができます。 多くのフィールドは、 %d としてではなく、 %s として出力されます。 このため、 フラグが期待通りに動作しないことも発生します。 一方で、 `-' フラグ (フィールドを必ず左揃えにする指定) を使えば、 必ず動作します。 -print とは違って、 -printf は、 文字列の末尾に改行文字を追加しません。 エスケープとディレクティブには、 以下のものがあります。

-prune

true を返します。 処理対象がディレクトリである場合、 ディレクトリ内に入っていきません。 -depth が指定してあると、 -prune は何もしません。 -delete の指定には、 暗に -depth の指定が含まれているので、 -prune と -delete を同時に使うことはできません。 たとえば、 src/emacs というディレクトリとその下にあるファイルやディレクトリはスキップするとします。 そしてそれ以外のファイルを表示しようとする場合には、 以下のように実行します。

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

-quit

すぐに終了します (エラーが発生していなければ 0 を返します)。 これは -prune とは異なります。 -prune は、 適用されたディレクトリの内容を、 対象外とするものですが、 -quit は単純に find をその場で止めます。 子プロセスが残ることはありません。 コマンドラインが、 -exec ... + や -execdir ... + の形式で構成されていた場合、 そのコマンドはすべて呼び出されてから、 プログラムが終了します。 -quit が実行されると、 コマンドライン上に指定されていた残りのファイルは、 処理されません。 たとえば `find /tmp/foo  /tmp/bar -print -quit` では、 `/tmp/foo` だけが表示されます。
-quit を利用するごく普通のケースとして、 ファイルシステム内から検索したいものが見つかったら、 検索をやめるという使い方があります。 たとえば、 1 つのファイルだけを見つけたい場合には、 以下のようにすることができます。

find / -name needle -print -quit

オペレーター

以下ではオペレーターを、 優先順位の高いものから順に示します。

( expr )

カッコ内を優先的に処理します。 シェルにとって、 カッコには特別な意味があるため、 普通はクォートでくくる必要があります。 このマニュアルページであげている例では、 この目的でバックスラッシュを多用しています。 つまり `(...)' は、 `\(...\)' のように記述しています。

! expr

expr が false の場合に　true となります。 通常この記号も、 シェルによって解釈されないようにする必要があります。

-not expr

! expr と同様ですが、 POSIX には準拠していません。

expr1 expr2

2 つ並んだ式は、 暗に -a によって結合されたものとして扱われます。 そして expr1 が false の場合、 expr2 は評価されません。

expr1 -a expr2

expr1 expr2 と同じです。

expr1 -and expr2

expr1 expr2 と同様ですが、 POSIX には準拠していません。

expr1 -o expr2

OR 結合です。 expr1 が true のとき、 expr2 は評価されません。

expr1 -or expr2

expr1 -o expr2 と同様ですが、 POSIX には準拠していません。

expr1 , expr2

リストを表します。 必ず expr1 と expr2 の両方が評価されます。 expr1 の値は無視されて、 expr2 の値が、 リストとしての値になります。 このカンマオペレーターは、 さまざまな種類のものを探すときに便利です。 ただしファイルシステム内の検索は、 一度しか行われません。 さまざまなものに一致した結果を、 複数ファイルに出力するには、 -fprintf アクションを利用します。

暗に -a の指定を意図した場合 (たとえばテストとテストの間に、 このオペレーターを記述しなかった場合)、 あるいは明示的に指定した場合は、 -o よりも優先順位が高いことを覚えておいてください。 たとえば、 find . -name afile -o -name bfile -print とした場合、 afile が出力されることはない、 ということです。

単純な `find|xargs` のアプローチ

•

/tmp ディレクトリ以下にある、 core という名前のファイルを探して、 それを削除します。

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


    

ただし、 ファイル名の中に、 改行、 シングルクォート、 ダブルクォート、 空白文字が含まれる場合には、 このコマンドは正しく動作しません。

安全な `find -print0 | xargs -0` によるアプローチ

•

/tmp ディレクトリ以下にある、 core という名前のファイルを探して、 それを削除します。 ファイルやディレクトリの名前に、 シングルクォート、 ダブルクォート、 空白、 改行などが含まれていても、 適切に処理されます。

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


    

テスト -name は、 -type よりも前に置いています。 これは、 stat(2) の呼び出しが、 すべてのファイルに対して行われることを防ぐためです。

ただし、 find がファイルシステム内を検索して、 一致するファイルを出力する時間と、 xargs によるコマンド起動がそのファイルを処理する時間との間では、 まだ競合が発生する点に注意してください。

任意の検索開始ポイントからの処理

•

プログラム proggy というものがあるとして、 あらかじめ処理を行って、 大量のNUL 区切りのファイル一覧を作るものであったとします。 これを検索開始ポイントととして処理を行って、 その中から通常ファイルと空のファイルを検索します。

$ proggy | find -files0-from - -maxdepth 0 -type f -empty


    

`-files0-from -` と記述している部分は、 検索開始ポイントとする名前を 標準入力 から、 つまりパイプから読み込むことを表しています。 そして -maxdepth 0 はサブディレクトリへの再帰的な検索は行わずに、 そこに明示された対象のみを検索するようにしています (検索開始ポイントの指定がただ 1 つである場合)。

各ファイルに対するコマンド実行

•

カレントディレクトリ以下の各ファイルに対して file を実行します。

$ find . -type f -exec file '{}' \;


    

波カッコをシングルクォートで囲んでいる点に注意してください。 これは、 句読点がシェルスクリプトの記号として、 解釈されないようにするためです。 同様のこととして、 セミコロンもバックスラッシュを使ってエスケープしています。 シングルクォートを使うのでもかまいません。

性能やセキュリティのことを考慮すると、 `-exec ... +` という記述が望まれるケースが多いかもしれません。

異なる 2 つのアクション、 ファイルシステム検索は 1 回

•

ファイルシステムを検索するのは 1 回だけにして、 setuid ビットが立っているファイルやディレクトリの一覧は /root/suid.txt に出力し、 サイズが大きいファイルの一覧は /root/big.txt に出力するようにします。

$ find / \


\( -perm -4000 -fprintf /root/suid.txt '%#m %u %p\n' \) , \


\( -size +100M -fprintf /root/big.txt '%-10s %p\n' \)




    

この例では、 初めの 2 つの行に対して、 行継続文字 '\' を用いています。 シェルがコマンド読み込みを行うにあたって、 次の行も継続して読み込むように指示しています。

期間の指定を使ったファイル検索

•

ホームディレクトリ内のファイルの中から、 修正時間が 24 時間未満のファイルを検索します。

$ find $HOME -mtime 0


    

このコマンドがそういう動作になるのは、 各ファイルの最終更新時間が、 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


    

上のコマンドは 3 つとも同じ動作をします。 1 つめは、 ファイルの許可属性を 8 進数で表しています。 残りの 2 つは、 シンボルによる表現形式を利用しています。 ファイルが一致する際には、 所有者とグループの両方が書き込み可能である必要はなく、 どちらか一方が満たされれば一致します。

•

ファイルの所有者あるいはグループが、 ともに書き込み可能であるようなファイルを探します。

$ 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


    

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

除外 - ファイルやサブディレクトリの除き方

•

/source-dir の内容を /dest-dir にコピーします。 ただし .snapshot という名前のファイル、 またはディレクトリ (その中身) は除きます。 さらに、 名前が `~' で終わるファイル、 またはディレクトリも除きますが、 その中身までは除きません。

$ cd /source-dir
$ find . -name .snapshot -prune -o \( \! -name '*~' -print0 \) \




| cpio -pmd0 /dest-dir




    

-prune -o \( ... -print0 \) という形は、 ごく普通に利用されます。 考え方としては、 -prune の前にある式が、 取り除く対象になるということです。 アクション -prune 自体は、 返り値として true を返します。 したがって、 直後に -o があるおかげで、 取り除き (prune) の対象にならなかったディレクトリが、 -o の右辺によって評価されることになります (取り除きの対象になったディレクトリの中身は、 処理の対象になっていないので、 中身を考慮する必要はありません)。 -o の右辺の式をカッコで囲んでいるのは、 わかりやすくするためです。 このように記述することで、 アクション -print0 の処理対象が、 -prune の処理対象以外あることが、 はっきりします。 テストとテストの間にある `and' 条件は、 -o よりも強く結びつくものであって、 それがデフォルトになっていますが、 カッコで囲めば、 どのように処理されるかがよくわかります。

•

以下に示されるようなプロジェクトディレクトリがあって、 さらに、 関連する SCM の管理ディレクトリがあるとします。 これに対して、 プロジェクトルートから効率の良い検索を行います。

$ find repo/ \


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




    

出力例:

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) は、 確実に検索されます。

この他の利用例

•

複数のファイルタイプを検索します。

$ find /tmp -type f,d,l


    

ファイルタイプとして、 カンマ区切りのリスト (GNU 拡張) を指定して、 それぞれファイル、 ディレクトリ、 シンボリックリンクを /tmp ディレクトリの中から検索します。 同じことは、 やや長くなりますが、 移植性の高い記述として、 以下のようにしても同じです。

$ find /tmp \( -type f -o -type d -o -type l \)


    

•

特定の名前 needle を持ったファイルを検索して、 最初にそれが見つかった時点で、 すぐに終了するようにします。

$ find / -name needle -print -quit


    

•

-printf アクションの書式ディレクティブ %f と %h が、 境界条件において、 どのように解釈されるかを示します。

$ find . .. / /tmp /tmp/TRACE compile compile/64/tests/find -maxdepth 0 -printf '[%h][%f]\n'
[.][.]
[.][..]
[][/]
[][tmp]
[/tmp][TRACE]
[.][compile]
[compile/64/tests][find]


    

意外なオペレーター優先順位

以下のようなコマンド find . -name afile -o -name bfile -print は、 afile を出力しません。 なぜなら実際には find . -name afile -o \( -name bfile -a -print \) と同じものだからです。 -a の優先順位は -o よりも高いことを忘れないでください。 またテストとテストの間に、 オペレーターが指定されていないければ、 -a であるとみなされる点も注意してください。

エラーメッセージ “paths must precede expression”

$ find . -name *.c -print
find: paths must precede expression
find: possible unquoted pattern after predicate `-name'?

*.c というパターンをシェルが展開した際に、 カレントディレクトリの複数ファイルに該当した場合に、 このエラーが発生します。 この場合には、 対象となったファイル名が、 find におけるコマンドライン上に、 以下のように受け渡されることになります。

find . -name frcode.c locate.c word_io.c -print

上のコマンドは、 もちろん動作しません。 述語表現である -name の引数は、 パターンを 1 つしか受けつけないからです。 そのような記述とするのではなく、 パターンの表現部分は、 クォートでくくるか、 ワイルドカードをエスケープしてください。 以下のようにすることで、 ファイル名がシェルによって展開されることなく、 find のファイル名の一致検索の際に、 ワイルドカードを用いたパターン検索ができるようになります。

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