file は各引き数をテストして分類する。 ファイルシステムテスト、マジックナンバーテスト、言語テストの 順序で 3 つのテストを行う。 そのうちの最初に成功したテストで、ファイルタイプを表示する。
表示されるタイプには通常以下のうち 1 つの単語が含まれる。 text (このファイルには表示可能文字といくつかの一般的な制御文字のみが含まれ、 ASCII 端末で読んでも多分安全である)、 executable (このファイルにはプログラムをコンパイルした結果が含まれ、 UNIX カーネルなどにより実行可能な形式である)、 data その他のもの (data は通常「バイナリ」または表示不能なファイルである)。 ただしバイナリデータを含んでいる良く知られた形式のフォーマット (core ファイル、tar アーカイブなど) は例外である。 /usr/share/file/magic ファイルや file プログラム自身を変更する場合も、 これらのキーワードは変更しないこと。 人々は、ディレクトリ内の読み取り可能なファイルに対しては、 全て ``text'' が表示されると思っている。 Berkeley がかつてやったように、 ``shell commands text'' を ``shell script'' に変更したりしてはいけない。 ファイル /usr/share/file/magic は、このプログラムのソースディストリビューションのサブディレクトリ Magdir にある数多くの小さなファイルから機械的に作られている点に注意すること。
ファイルシステムのテストは、 stat(2) システムコールの結果の検討に基づいて行われる。 このプログラムは、ファイルが空であるかや、 特殊ファイルであるかをチェックする。 実行中のシステムに特有の既存のファイルタイプ (ソケット・シンボリックリンク・名前付きパイプ (FIFO) (ただしシステムで実装されている場合)) は、 システムのヘッダファイル <sys/stat.h> に定義されていれば、すぐに分かる。
マジックナンバーテストは、 特定の決まった形式のデータを含むファイルをチェックするのに使われる。 もっとも簡単な例は、バイナリ実行可能ファイル (コンパイルされたプログラム) a.out である。 この形式は標準インクルードディレクトリの a.out.h で定義されている (exec.h の場合もある)。 これらのファイルにはファイルの先頭付近の特定位置に 「マジックナンバー」が格納されている。 これにより UNIX オペレーティングシステムは、 ファイルがバイナリ実行可能であることが分かり、 そのうちのどのファイルタイプであるかも分かる。 「マジックナンバー」の考え方は、データファイルに対する拡張にも応用されている。 ファイルの先頭から近い場所に一定の識別子を持つファイルは、 通常はこの方法で記述できる。 これらのファイルについての情報識別子は、コンパイルされたマジックファイル /usr/share/file/magic.mgc から読み込まれる。 このコンパイルされたファイルがない場合は、 /usr/share/file/magic から読み込まれる。 更に file は $HOME/.magic.mgc または $HOME/.magic からマジックファイルのエントリを探す。
ファイルがマジックファイルのどのエントリともマッチしなかった場合、 テキストファイルであるかを調べる。 文字集合内の表示可能なテキストを構成する バイト列の範囲の違いを調べることにより、 ASCII, ISO-8859-x, (Macintosh や IBM PC システムで使用されている) ISO に準拠しない 8 ビット拡張 ASCII 文字集合、 UTF-8 エンコードされたユニコード、UTF-16 エンコードされたユニコード、 EBCDIC 文字集合を識別する。 ファイルがこれらのテストをパスすると、文字集合名が表示される。 ASCII, ISO-8859-x, UTF-8, 拡張 ASCII のファイルは、 これはほぼ全ての端末で読むことができるので、 ``text'' として識別される。 UTF-16 と EBCDIC のファイルは、 たとえテキストを含んでいたとしても読む前に変換が必要なので、 単なる ``character data'' とされる。 さらに file はテキスト型ファイルの他の特徴も決定しようとする。 ファイルの行が Unix で標準的な LF ではなく、 CR, CRLF, NEL で終了している場合は、その旨を表示する。 ファイルに組み込み (embedded) エスケープシーケンスや 重ね打ち (overstriking) が含まれている場合も、その旨を表示する。
file はテキスト型ファイルで使われている文字集合を決定した後は、 ファイルが書かれている言語を決定しようとする。 言語テストではファイルの最初の数ブロックのどこかに現れる特定の文字列 (names.h を参照) を探す。 例えばキーワード .br があれば、そのファイルは多くの場合 troff(1) の入力ファイルであることを示しており、 キーワード struct は C 言語プログラムであることを示している。 これらのテストは前のテストに比べると信頼性が低いので、 最後に実行される。 言語テストのルーチンは他のファイルタイプ (例えば tar(1) アーカイブ) に関するテストも行う。
上に挙げた文字集合のどれにも当てはまらないファイルは、 単に ``data'' と表示される。
System V バージョンとの重要な違いは、
このバージョンでは空白を区切り文字として扱うために、
パターン文字列における空白文字をしなければならないという点にある。
例えば、
>10 string language impress (imPRESS data)
という既存のマジックファイルは、
>10 string language\ impress (imPRESS data)
のように変更しなければならない。
更にこのバージョンでは、バックスラッシュを含むパターン文字列は
エスケープしなければならない。
例えば、
0 string \begindata Andrew Toolkit document
という既存のマジックファイルは、
0 string \\begindata Andrew Toolkit document
のように変更しなければならない。
Sun Microsystems の SunOS releases 3.2 以降には、
System V のものから派生した
file(1)
コマンドが含まれているが、いくつか拡張されている。
私の作ったバージョンは、Sun のものと些細な違いしかない。
Sun のバージョンは `&' オペレータの拡張が含まれ、
例えば以下のように使われる。
>16 long&0x7fffffff >0 not stripped
マジックファイルのエントリは順番が重要である。 使用しているシステムによっては、順番の組みが不正であるかもしれない。 古い file コマンドがマジックファイルを使っている場合、 比較のために古いマジックファイルを残しておくこと (/usr/share/file/magic.orig に名前を変更しておく)。
$ file file.c file /dev/{wd0a,hda}
file.c: C program text
file: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), stripped
/dev/wd0a: block special (0/0)
/dev/hda: block special (3/0)
$ file -s /dev/wd0{b,d}
/dev/wd0b: data
/dev/wd0d: x86 boot sector
$ file -s /dev/hda{,1,2,3,4,5,6,7,8,9,10}
/dev/hda: x86 boot sector
/dev/hda1: Linux/i386 ext2 filesystem
/dev/hda2: x86 boot sector
/dev/hda3: x86 boot sector, extended partition table
/dev/hda4: Linux/i386 ext2 filesystem
/dev/hda5: Linux/i386 swap file
/dev/hda6: Linux/i386 swap file
/dev/hda7: Linux/i386 swap file
/dev/hda8: Linux/i386 swap file
/dev/hda9: empty
/dev/hda10: empty
$ file -i file.c file /dev/{wd0a,hda}
file.c: text/x-c
file: application/x-executable, dynamically linked (uses shared libs),
not stripped
/dev/hda: application/x-not-regular-file
/dev/wd0a: application/x-not-regular-file
System V バージョンをベースにしたこのプログラムは、 誰のソースコードも見ずに Ian Darwin <ian@darwinsys.com> によって書かれた。
John Gilmore はコードを広範囲にわたって改訂し、 最初のバージョンより改良した。 Geoff Collyer はいくつかの欠点を見つけ、 マジックファイルエントリを提供した。 `&' オペレータについては 1989 年に Rob McMahon, cudcv@warwick.ac.uk が貢献した。
Guy Harris, guy@netapp.com は 1993 年から現在に至るまで 多くの変更を行っている。
Christos Zoulas (christos@astron.com) は 1990 年に最初の開発を行い、 現在までメンテナンスを行っている。
2000 年の Chris Lowth, chris@lowth.com による変更: 別のマジックファイルと内部ロジックを使い、 ``-i'' で mime タイプ文字列を出力するようにした。
2000 年 7 月の Eric Fischer (enf@pobox.com) による変更: 文字コードを識別し、非 ASCII ファイルの言語を識別するようにした。
"Magdir" ディレクトリ (/etc/magic ファイルのソース) の貢献者のリストは、 長すぎるのでここには含められない。 貢献してくれた人は自分が貢献したことを知っているでしょう。 感謝します。
ファイル tar.h と is_tar.c は John Gilmore によって書かれたもので、 彼のパブリックドメイン tar プログラムに由来する。 この 2 つのファイルには上記のライセンスが適用されない。
file には正確さよりも速度を重視したアルゴリズムが使われているため、 テキストファイルの内容を読み誤ることがある。
(主にプログラミング言語を対象とした) テキストファイルのサポートは、 単純化されていて不十分であり、更新するには再コンパイルが必要である。
後続の行を追っていくためには、``else'' 節を付けておくべきである。
マジックファイルとキーワードで正規表現をサポートすべきである。 ASCII TAB をフィールドの区切り文字として使用するのは、 見苦しく編集しづらいが、定着している。 例えば troff(1) コマンドに対する man ページのマクロのように、 キーワードで大文字を許可するようにするのが望ましいだろう。 正規表現がサポートされれば、これが簡単にできるだろう。
このプログラムは FORTRAN を判別できない。 開始行でインデントされているキーワードを見て、 FORTRAN であると判断すべきである。 正規表現がサポートされれば、これが簡単にできるだろう。
ascmagic にあるキーワードは、多分 Magic ファイルに入れるべきだろう。 これはオフセット値に `*' のようなキーワードを使うことで可能だろう。
その他の最適化としてはマジックファイルのソートがある。 これにより一度読み込んでしまえば、 最初のバイト・最初のワード・最初の long 型、... というように 全てのテストで突き止めていくことができる。 マジックファイルエントリの衝突について苦情を言ってください。 マジックファイルのエントリのソートは、 マジックファイルにおける位置ではなくファイルオフセットで行う、 というルールにするべきだろうか ?
推定した結果が「どのくらい良いか」を評価する手段を、 プログラムが提供すべきである。 最終的には (例えば ``Newsgroups:'' に対する ``Return-Path:'' のように) 他の推定結果より良くない推定結果 (例えば、ファイルの最初の 5 文字が ``From '' など) は削除する。 しかし他の推定結果が出なければ、 最初の推定結果を使えるようにしておくべきである。
このプログラムは、いくつかのベンダの file コマンドより遅い。 複数文字コードを新しくサポートしたことで、いっそう遅くなってしまった。