温故知新 linux実践講座

温故知新 linux実践講座

温故知新。linuxを使いこなしてみよう。

ホーム » コマンド入門 » find コマンド

— 広告 —


— 広告 —

find コマンド

所要時間 約 109分

find コマンドは使い方を知れば知るほど便利なコマンドです。一般的には find /hogehoge -name "*hoge*.jpg" といった使い方をしますが、オプションを組み合わせると色々な事が出来てしまいます。便利な find コマンドの使い方を覚えましょう。
-name
オプションとオプションを -o でつなぐと OR 条件になります。

$ find /directory \( -name "*.jpg" -o -name "*.png" \)

-exec
条件に合致したファイルに対して -exec 移行に指定したコマンドを実効する。
/hoge/hoge ディレクトリ下にある *.jpg ファイルを削除する。

$ find /hoge/hoge -name "*.jpg" -exec rm -f {} \;

-path
指定したパターンマッチングな文字列を元にファイルまでのパスを検索します。
/home/hoge ディレクトリ下から hogeword という文字列が記述されたファイルを検索しマッチした行とファイル名を表示する。

find /home/hoge -type -f -path "*" -exec grep "hogeword" {} \; -print

-user、-group
/hoge/hoge ディレクトリ下で オーナーが nobody のファイル、ディレクトリをオーナー apacheに変更する。

find /hoge/hoge -user nobody -exec chown apache.apahce {} \;

-atime、-ctime、-mtime、分単位なら-amin、-cmin、-mmin
ファイルのタイムスタンプを元に検索。-atim は最後にアクセス、-ctime は最後にステータスが変更、 -mtime は最後に修正されたタイムスタンプを調べます。引数の数字に、‘+’や‘-’を付加することで、日数*24時間より古いファイル(+)、新しいファイル(-)を検索することができます。
3日以内に修正されたファイルを表示する。

find /hoge/hoge -type -f -mtime -4 -exec ls -l {} \;

find コマンド man より

名前
find - ディレクトリ階層をたどって、条件を満たすファイルを検索する
書式
find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]
説明
このマニュアルページは GNU 版 find の使用法を説明している。 GNU 版 find は、指定されたファイル名 (訳注: 上記「書式」における path...、 普通はディレクトリを指定する) を始点とするディレクトリツリーを 一つづつ探索し、与えられた式 (expression) を、 優先規則に従いつつ (「演算子」セクションを参照)、左から右へ 評価することによって検索を行う。 結果が確定すると (たとえば、and 演算なら左辺が偽になった時点で、 or 演算なら左辺が真になった時点で)、 find は検査の対象を次のファイル名に移す。

もし find を使用しているのが、セキュリティの問題をおろそかにできない環境なら (たとえば、 find を使って探索しているディレクトリが、自分以外のユーザにも 書き込み可能な場合など)、findutils 関連文書の 「Security Considerations」の章をお読みになるとよいだろう。 Finding Files という文書で、findutils に同梱されているはずだ (訳注: info "Finding Files" や info find で読むことができる)。 その文書では、ほかの点についてもこのマニュアルページより はるかに詳しい説明や考察が行われているので、この文書以上に情報源として お役に立つかもしれない。
オプション
-H, -L, -P というオプションは、シンボリックリンクをどう処理するかを決める。 こうしたオプションに続くコマンドライン引き数は、探索場所となる ファイル名やディレクトリ名と見なされる。ただし、それは、`-' で始まる 引き数や、`(' とか `!' という引き数が、続いて現れるまでだ。 そうした引き数、及びそれに続くいかなる引き数も、何を捜すべきかを 記述した式であると解釈される。パスが一つも指定されていない場合は、 カレントディレクトリ以下が探索の対象になる。 式が一つも指定されていない場合は、 -print が式として使用される (もっとも、 -print の代わりに、 -print0 の使用を考えた方がよさそうだが)。

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

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

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

-H
コマンドライン上で指定された引き数を処理するとき以外、 シンボリックリンクをたどらない。すなわち、原則として、 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 の出力を見るとよい。 有効なデバッグオプションの中には、以下のものがある。

help
デバッグ用オプションを説明する。
tree
式の構造 (expression tree) をオリジナルな形と最適化した形で示す。
stat
stat や lstat システムコールを使ってファイルが調べられたとき、 メッセージを表示する。 find プログラムは、そうしたシステムコールの回数を最少にしようとする。
opt
式の構造 (expression tree) の最適化に関する診断情報を表示する。 -O オプションを参照。
rates
各述語が何回成功し、何回失敗したかを示す情報を要約して表示する。

-Olevel
検査の最適化を有効にする。 find プログラムは、実行速度を上げるために判別式の順序を並べ替えるとき、 全体的な効果を維持しようとする。すなわち、付加的な作用のある 述語同士については、相互の相対的な順序を変更しないということだ。 各最適化レベルで行われる最適化は、以下のとおりである。

0
最適化レベル 1 と同じである。
1
これはデフォルトの最適化レベルであり、伝統的な動作に当たる。 式を並べ替えるとき、ファイル名にのみ基づいた判別式 (たとえば、 -name や -regex) が先に実行されるようにする。
2
判別式 -type や -xtype の実行は、ファイル名に基づいたいかなる判別式よりも後になるが、 inode から情報を取得する必要があるどんな判別式よりも先になる。 最近の Unix には readdir() 関数でファイルタイプを取得できるものが多い。 それ故、こうした述語は、まず stat 関数でファイル情報を取得する 必要がある述語よりも、評価に時間がかからないのである。
3
この最適化レベルでは、コストに基づいた検査の最適化を徹底して行う機能が 有効になる。判別式の順序が必要なら変更され、コストのかからない (すなわち、速い) 判別式が先に行われ、よりコストのかかる判別式が 後回しにされる。コストがほぼ同じ場合には、その述語が真を返しそうか、 偽を返しそうかによって、評価の順番が変わってくる。 or 演算では、真を返しそうな述語が先に評価され、 and 演算では、偽になりそうな述語が先に評価されるのである。

コストに基づいた最適化機能は、ある判別式が真を返す確率について 一定の考えを持っている。場合によっては、その確率について、 問題のテストの特性が考慮されることもある (たとえば、 -type f は、 -type c よりも、真になる可能性が高いと見なされる)。 コストに基づいた最適化機能は、現在のところその効果を評価中である。 もし、それによって find の性能が実際に向上することがなければ、捨てられることになるだろう。 反対に、信頼性があり、問題を起こしにくく、効果的であることが はっきりした最適化は、そのうち下位の最適化レベルでも採用される かもしれない。とは言え、リリース 4.3.x のシリーズでは、 デフォルトの動作 (すなわち、最適化レベル 1) を変更する予定はない。 なお、findutils のソースに付属するテスト集は、そのテストのすべてを 各最適化レベルの find で実行して、どの最適化レベルでも結果が同じになることを保証している。

式 (EXPRESSIONS)
式は、オプション、判別式、アクションから構成されている (訳注: オプション、判別式、アクションをまとめて、「述語 (predicate)」と呼ぶ)。 オプションは特定のファイルの処理よりもむしろ作業全体に影響し、 常に真を返す。判別式が返す値は、真のこともあれば、偽のこともある。 アクションには付加的な作用があり、真または偽を返す。 こうした式の要素は、みな演算子で区切られる。演算子が省略された場所には、 -and があるものと見なされる。

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

すべてのオプションは常に真を返す。 -daystart, -follow, -regextype を除いて、そのほかのオプションは、そのオプションより前に 指定された判別式も含め、すべての判別式に影響を及ぼす。 これは、オプションの処理は、コマンドラインが解析されるときに 行われるのに対して、判別式の方は、ファイルが調べられるまで 何もしないからである。 -daystart, -follow, -regextype の各オプションはこの点で異なっている。この三つのオプションは、 コマンドラインで自分より後に指定された判別式にしか影響を 及ぼさないのだ。従って、混乱を避けるためには、 -daystart, -follow, -regextype 以外のオプションは、 式の先頭部に置いた方がよい。そうしないと、警告が発せられる。

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

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

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

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

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

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

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

-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 少ない 数だけサブディレクトリを stat 関数で調べた時点で、ディレクトリ中の 残りのエントリはディレクトリではない (ディレクトリツリー中の `leaf 葉っぱ' ファイルである) とわかるわけである。 もし、調べるのがファイル名だけで充分なら、ファイルに対して stat 関数を 実行する必要はない。そこで、この動作により、検索速度が いちじるしく向上するわけだ。

-regextype type
判別式 -regex と -iregex が理解する正規表現の文法を変更する。 このオプションよりコマンドラインの後方で指定する -regex などに対して効果がある。 現在実装されている文法のタイプには、emacs (デフォルトである), posix-awk, posix-basic, posix-egrep, posix-extended がある。

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

-warn, -nowarn
警告メッセージの表示、非表示を切り替える。こうしたメッセージは、 もっぱらコマンドラインの使用法に関するものであり、 find がディレクトリを探索中に出会うかもしれない何らかの状況に 関するものではない。デフォルトの動作は、標準入力が tty であれば、 -warn であり、それ以外の場合は、 -nowarn である。

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

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

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

+n
n を越える数であることを意味する。
-n
n 未満であることを意味する。
n
ぴったり n であることを意味する。

-amin n
ファイルの最終アクセス日時が n 分前であれば真。

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

-atime n
ファイルの最終アクセス日時が n 日前ならば、真を返す。 ファイルの最終アクセス日時が何日前かを計算する際、現在時刻との時間差を 24 で割った余りは切り捨てられる。従って、 -atime +1 にマッチするためには、 ファイルは少なくとも二日前にアクセスされていなければならない。

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

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

-ctime n
ファイルの最終ステータス変更日時が n 日前ならば、真を返す。 何日前かを計算する際に、現在時刻との時間差を 24 で割った余りを 切り捨てることが、ファイルのステータス変更日時の解釈にどんな影響を 及ぼすかについては、 -atime の説明を見てほしい。

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

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

-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 オプションが有効な場合は、シンボリックリンクがリンク切れしている場合を除き、 この判別式は偽を返す。

-iname pattern
-name と同じだが、大文字小文字を区別しない。 たとえば、パターン `fo*' や `F??' は、`Foo', `FOO', `foo', `fOo' といったファイル名とマッチする。シェルのファイル名展開と違い、 こうしたパターンにおいて '*' は、ファイル名の先頭にある '.' とも マッチする。すなわち、 find -name *bar は、ファイル `.foobar' ともマッチすることになるわけだ。 当然ながら、パターンは引用符で囲むべきだということに気をつけて いただきたい。さもないと、パターン中にワイルドカード文字があれば、 シェルがそれを展開してしまうことになる。

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

-ipath pattern
-iwholename と同じように動作する。この判別式は非推奨である。使わないでいただきたい。

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

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

-links n
ファイルのリンク数が n ならば真。

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

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

-mtime n
ファイルの最終内容更新日時が n 日前ならば、真を返す。 何日前かを計算する際に、現在時刻との時間差を 24 で割った余りを 切り捨てることが、ファイルの内容更新日時の解釈にどんな影響を 及ぼすかについては、 -atime の説明を見てほしい。

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

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

-newerXY reference
目下検査の対象になっているファイルのタイムスタンプを reference と 比較する。引き数 reference は、たいていの場合ファイル名であるが (そして、そのタイムスタンプの一つが 比較に使用されるが)、日時を直接表す文字列でも構わない。 X と Y は仮の表現であって、実際には以下に述べるような別の文字が来る。 そうした文字が、検査の対象になっているファイルとリファレンスそれぞれの、 どの日時を比較に使用するかを決めるのである (訳注: 前者を X で、 後者を Y で指定する)。
a ファイルのアクセス日時
B ファイルの作成日時
c inode のステータスが変更された日時
m ファイルの内容が更新された日時
t reference が日時の直接表現として解釈される

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

-nogroup
ファイルのグループ ID 番号に対応するグループが存在しなければ真。

-nouser
ファイルのユーザ ID 番号に対応するユーザが存在しなければ真。

-path pattern
ファイル名がシェルのパターン 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
述語 -path は、HP-UX の find でもサポートされている。 POSIX 標準の次期バージョンでも採用されることになるだろう。

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

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

-perm /mode
mode で指定した許可属性ビットのどれかが、ファイルでも立っていれば、 真を返す。mode 指定のこの形式でも、シンボルによる許可属性表現が 使用できる。シンボルによる表現を使用する場合は、`u' や `g' や `o' を きちんと指定しなければならない。具体例については「用例」セクションを 見てほしい。 mode で許可属性ビットが一つも立っていない場合、この判別式は いかなるファイルにもマッチする (すなわち、 -perm -000 の動作と同じだということだ)。

-perm +mode
非推奨な形式。mode で指定した許可属性ビットのどれかが立っている ファイルを捜す古い方法である。代わりに -perm /mode を使用した方がよい。`+' を付けて mode を指定するこの形式で シンボルによる表現を使おうとすると、思いがけない結果を生むことがある。 たとえば、 `+u+x' はそれ自体有効なシンボル表現である ('+u,+x' と 同じであり、0111 を意味する)。そのため、 -perm +u+x は、 -perm +mode として評価されず、ぴったり一致する許可属性を指定するときの -perm mode として評価されてしまうのだ。その結果、実行ビットが少なくともどれか一つ 立っているファイルではなく、許可属性がぴったり 0111 のファイルに マッチすることになる。もし、この項の説明がわかりにくかったとしても、 あなた一人がわからないのではない。とりあえず、 -perm /mode を使っておいていただきたい。判別式 -perm のこの形式が非推奨なのは、シンボルによる許可属性に先行する `+' は、 シンボル表現の一部として解釈するように POSIX の規定で要求されて いるからであり、それ故、我々は '+' に代えて、'/' を使うようにしたのである。

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

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

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

-size n[cwbkMG]
ファイルが n 単位分の領域を使用していれば、真を返す。 以下の接尾辞が使える。

`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 の動作と異なっている。

-true
常に真。

-type c
ファイルのタイプが c であれば真。c の位置には実際には 以下の文字が来る。

b
ブロック・スペシャルファイル (バッファあり)
c
キャラクタ・スペシャルファイル (バッファなし)
d
ディレクトリ
p
名前付きパイプ (FIFO)
f
通常のファイル
l
シンボリックリンク。オプション -L や -follow が有効な場合、シンボリックリンクがリンク切れの場合を除いて、 この判別式が真になることはない。 -L が有効なときにシンボリックリンクを検索したかったら、 -xtype を使うべきである。
s
ソケット
D
ドア (Solaris の場合)

-uid n
ファイル所有者のユーザ ID 番号が n ならば真。

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

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

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

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

-xtype c
検査の対象となるファイルがシンボリックリンクでないかぎり、 -type と同じである。ファイルがシンボリックリンクのときは、以下のように動作する。 -H や -P オプションが指定された場合は、リンク先の ファイルのタイプが c ならば、真を返す。他方、 -L オプションが指定されている場合は、c が `l' ならば、真を返す。 言い換えると、ファイルがシンボリックであるとき、 -xtype は、 -type が検査しない方のファイルのタイプを検査するわけだ。

アクション

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-printf format
真を返す。標準出力に format を出力する。 そのとき format 中の `\' によるエスケープシーケンスと、`%' に 始まる書式指定子を認識して変換する。 フィールドの幅や精度は、C 言語の `printf' 関数と同じやり方で 指定できる。フィールドの多くは、(`printf' 関数流に言うと) %d ではなく、%s として出力されることに注意していただきたい。 すなわち、フラグが期待通りに効かないかもしれないのだ。だが、 それはまた、`-' フラグ (フィールドを強制的に左揃えにする) が 使えるということでもある。 -print とは違って、 -printf は文字列の末尾に改行文字を付加しない。 バックスラッシュ・エスケープシーケンスと書式指定子は以下のとおりである。

\a
警告ベル。
\b
バックスペース。
\c
このフォーマットによる出力をただちに停止し、出力バッファを フラッシュする。
\f
フォームフィード文字。
\n
改行文字。
\r
復帰文字。
\t
水平タブ。
\v
垂直タブ。
\0
ASCII NUL 文字。
\\
バックスラッシュ文字そのもの (`\')。
\NNN
ASCII コードが NNN (8 進数) の文字。

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

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

@
Jan. 1, 1970, 00:00 GMT からの経過秒数。小数点以下も表示する。

時刻フィールド:

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

日付フィールド:

a
現在のロケールによる曜日の短縮形 (Sun..Sat)
A
現在のロケールによる曜日のフル表示。長さは可変 (Sunday..Saturday)
b
現在のロケールによる月名の短縮形 (Jan..Dec)
B
現 在 のロケールによる月名のフル表示。長さは可変 (January..December)
c
現在のロケールによる日付と時刻の表示 (Sat Nov 04 12:02:33 EST 1989)。 この表示形式は ctime(3) のものと同じであり、 ctime(3) の形式との互換性を維持するためにそうなっている。秒には小数点以下が付かない。
d
その月の何日目かの表示 (01..31)
D
日付 (mm/dd/yy)
h
b と同じ
j
その年の何日目かの表示 (001..366)
m
月 (01..12)
U
その年の何週目か (日曜日を週の始まりとする) (00..53)
w
その週の何日目か (0..6)
W
その年の何週目か (月曜日を週の始まりとする) (00..53)
x
現在のロケールによる日付表示 (mm/dd/yy)
y
年の後ろ二桁 (00..99)
Y
年 (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 である。

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

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

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

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

[訳注]:
バージョン 4.4.0 以降の find では、-prune の動作が 上記の説明と少し異なっている。すなわち、「-depth が指定して あるときは、何もしない」のは、それまでのバージョンと同じだが、 返り値は真を返している。ご自分で、 find . -depth -path "./foo" -prune -print などを実行して、確認していただきたい。-prune が真を返していれば、 ディレクトリ ./foo が表示されるはずだ。

-quit
直ちに終了する。動いている子プロセスを残したまま終了したりはしないが、 コマンドラインで指定したパスをこれ以上処理することはない。たとえば、 find /tmp/foo /tmp/bar -print -quit は、 /tmp/foo を表示するだけである。 -execdir ... {} + によってすでに作成されたコマンドラインがあれば、 find が終了する前に、呼び出して実行する。終了ステータスは、 エラーがすでに起きているかどうかよって、0 のことも、0 でないこともある。

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

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

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

-printf, -fprintf
出力先が端末でない場合は、そのまま出力される。端末の場合は、 使用される書式指定子によって、結果は様々である。 書式指定子 %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 や -fls におけるクォート方法とは違うということだ。 もし、 find の出力に使う形式を自由に決めることができるならば、たいていの場合、 終端文字に改行ではなく、`\0' を使用した方がよい。 ファイル名には空白や改行が含まれていることがあるからだ。 どの文字がクォートを必要とするかを判断するには、環境変数 `LC_CTYPE' の設定が 使用される。

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

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

演算子

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

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

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

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

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

expr1 -a expr2
expr1 expr2 と同じ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[訳注]:
Linux や BSD 系 Unix のようにディレクトリへのハードリンクを 作成できない Unix もある。その場合は、上記のハードリンクに関する 解説は当てはまらない。

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

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

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

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

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

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

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

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

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

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

終了ステータス

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

関連項目
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), Finding Files (on-line in Info, or printed).
履歴
findutils-4.2.2 以来、ファイル名のパターンに使われたシェルのメタ文字 (`*', `?', `[]' など) は、先頭の `.' にマッチする。これは、 IEEE POSIX interpretation 126 がそう要求しているからである。

-perm +MODE という書き方は findutils-4.2.21 で非推奨になった。 -perm /MODE を使用する方をお勧めする。 findutils-4.3.3 以来、 -perm /000 はどんなファイルにもマッチしないではなく、すべてのファイルにマッチする になっている。

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

findutils-4.3.11 以来、アクション -delete は、実行に失敗すると、 find の終了ステータスを 0 以外の値に設定する。とは言え、 -delete に失敗したとき、 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

バグにあらず

$ 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

バグ

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 メールを送っていただきたい。

-- 広告 -- -- 広告 --

 

この記事に関連する記事一覧

アフィリエイトで稼ぐ
プロフィール

ぴよふぁくとりぃです。

職業は自宅でサーバ管理、資格は薬剤師です。
趣味も職業もパソコンラブです。
よろしくね。
連絡先: admin@arakanoj.com
URL: http://piyofactory.com

検索
人気ページ
東京電力予想最大電力(万kW)
twitter
使い方を知れば知るほど楽しく使える Linux。
Linux の基本を覚えてもっともっと楽しいコンピュータの使い方を身につけましょう。