Next: 本当の名前, Previous: アクセシビリティのテスト, Up: ファイルの情報 [Contents][Index]
このセクションではディレクトリー、シンボリックリンク、および通常ファイルのようなさまざまな種類のファイルを区別する方法を説明します。
シンボリックリンクは通常はそれが出現した場合には常にフォローされます。たとえばファイル名a/b/cを解釈するためにシンボリックリンクかもしれないa、a/b、a/b/cはすべてフォローされて、リンクターゲット自身がシンボリックリンクなら再帰的にフォローされるかもしれません。しかしいくつかの関数は最後のファイル名(この例ではa/b/c)ではシンボリックリンクをフォローしません。そのような関数のことをシンボリックリンク非フォロー(not follow symbolic links)と呼びます。
ファイルfilenameがシンボリックリンクならfile-symlink-p関数はリンクをフォローせずに、かわりにリンクターゲットを文字列としてリターンする(リンクターゲット文字列はターゲットの完全な絶対ファイル名である必要はない。リンクが指すのが完全なファイル名かどうかを判断するのは簡単な処理ではない。以下参照)。
file-symlink-pはファイルfilenameがシンボリックリンクではないか、あるいは存在しなかったりシンボリックリンクかどうか判断するのに問題がある場合にはnilをリターンする。
この関数の使用例をいくつか示す:
(file-symlink-p "not-a-symlink")
⇒ nil
(file-symlink-p "sym-link")
⇒ "not-a-symlink"
(file-symlink-p "sym-link2")
⇒ "sym-link"
(file-symlink-p "/bin")
⇒ "/pub/bin"
3つ目の例では関数はsym-linkをリターンするが、たとえそれ自体がシンボリックリンクであってもリンク先の解決を行わないことに注意。これは関数がシンボリックリンクをフォローしない、すなわちシンボリックリンクをフォローする処理はファイル名の最後のコンポーネントには適用されないからである。
この関数がリターンするのはそのシンボリックリンクに何が記録されているかを示す文字列であり、それにディレクトリー部分が含まれているかどうかは構わない。この関数は完全修飾されたファイル名を生成するためにリンクターゲットを展開しないし、リンクターゲットが絶対ファイル名でなければ、(もしあっても)filename引数のディレクトリー部分は使用しない。以下に例を示す:
(file-symlink-p "/foo/bar/baz")
⇒ "some-file"
ここでは、たとえ与えられた/foo/bar/bazが完全修飾されたファイル名であるにも関わらずその結果は異なり、実際には何のディレクトリー部分ももたない。some-file自体がシンボリックリンクかもしれないので、単にその前に先行ディレクトリーを追加することはできず、絶対ファイル名を生成するために単にexpand-file-name
(ファイル名を展開する関数を参照)を使用することもできないからである。
この理由により、あるファイルがシンボリックリンクか否かという単一の事実よりも多くを判定する必要がある場合にこの関数が有用であることは稀である。実際にリンクターゲットのファイル名が必要なら、本当の名前で説明するfile-chase-linksやfile-truenameを使用すること。
この関数はfilenameが既存のディレクトリー名ならt。filenameがディレクトリー名ではない、あるいはディレクトリーかどうかの判断に問題がある場合にはnilをリターンする。この関数はシンボリックリンクをフォローする。
(file-directory-p "~rms")
⇒ t
(file-directory-p "~rms/lewis/files-ja.texi")
⇒ nil
(file-directory-p "~rms/lewis/no-such-file")
⇒ nil
(file-directory-p "$HOME")
⇒ nil
(file-directory-p
(substitute-in-file-name "$HOME"))
⇒ t
この関数はファイルfilenameが存在して、それが通常ファイル(ディレクトリー、名前付きパイプ、端末、その他I/Oデバイス以外)ならtをリターンする。filenameが存在しない、通常ファイルではない、あるいは通常ファイルかどうかの判断に問題がある場合にはnilをリターンする。この関数はシンボリックリンクをフォローする。