Provided by: manpages-ja-dev_0.5.0.0.20221215+dfsg-1_all bug

名前

       realpath - 正規化された絶対パス名を返す

書式

       #include <limits.h>
       #include <stdlib.h>

       char *realpath(const char *path, char *resolved_path);

   glibc 向けの機能検査マクロの要件 (feature_test_macros(7)  参照):

       realpath():
           _XOPEN_SOURCE >= 500
               || /* glibc 2.19 以降: */ _DEFAULT_SOURCE
               || /* glibc 2.19 以前: */ _BSD_SOURCE

説明

       realpath()   は path として与えられたヌル終端された文字列中の すべてのシンボリックリンクを
       展開し、 /./, /../ による参照や余分な  '/'  を解決して、正規化された絶対パス名を生成する。
       得られた絶対パス名は、最大で  PATH_MAX  バイトのヌル終端された文字列として、 resolved_path
       により参照されるバッファーに格納される。  結果として返るパスの中には、シンボリックリンクや
       /./, /../ といった要素は含まれない。

       resolved_path に NULL が指定されると、 realpath()  は malloc(3) を使って解決したパス名を保
       持するためのバッファーを 最大で PATH_MAX  バイトまで割り当て、このバッファーへのポインター
       を返す。 呼び出し元は、 free(3)  を使ってこのバッファーを解放すべきである。

返り値

       エラーがなかった場合、 realpath()  は resolved_path へのポインターを返す。

       それ以外の場合は NULL が返り、配列 resolved_path の内容は不定となり、 errno にエラーの内容
       を示す値がセットされる。

エラー

       EACCES パスのディレクトリ部分に、読み出し許可または検索許可が与えられていない。

       EINVAL path が NULL である。 (バージョン 2.3 より前の glibc では、 resolved_path  が  NULL
              の場合にもこのエラーが返される。)

       EIO    ファイルシステムを読むときに、I/Oエラーが起こった。

       ELOOP  パス名の変換にあたり、解決すべきシンボリックリンクの数が多過ぎた。

       ENAMETOOLONG
              パス名の一要素の文字数が NAME_MAX を越えている、またはパス名全体の文字数が PATH_MAX
              を越えている。

       ENOENT 指定されたファイルが存在しない。

       ENOMEM メモリ不足。

       ENOTDIR
              パスのディレクトリ要素が、ディレクトリでない。

属性

       この節で使用されている用語の説明については、 attributes(7) を参照。

       ┌─────────────────┬───────────────┬─────────┐
       │インターフェース属性      │
       ├─────────────────┼───────────────┼─────────┤
       │realpath()       │ Thread safety │ MT-Safe │
       └─────────────────┴───────────────┴─────────┘

準拠

       4.4BSD, POSIX.1-2001.

       POSIX.1-2001   では   resolved_path   が   NULL   の場合の動作は実装に依存するとしている。
       POSIX.1-2008 では、このマニュアルページに書かれている動作が規定されている。

注意

       4.4BSD  と  Solaris  では、パス名の長さの上限は (<sys/param.h> の中にある) MAXPATHLEN であ
       る。SUSv2 では PATH_MAXNAME_MAX が規定されており、 これらは <limits.h>  で定義されてい
       るか、 pathconf(3) 関数から得られる。以下のようなソースコードになっていることが多い。

           #ifdef PATH_MAX
             path_max = PATH_MAX;
           #else
             path_max = pathconf(path, _PC_PATH_MAX);
             if (path_max <= 0)
                                             path_max = 4096;
           #endif

       (バグの章も参照のこと。)

   GNU による拡張
       呼び出しが  EACCESENOENT で失敗し resolved_path が NULL でない場合、読むことができな
       い、もしくは存在しない path のディレクトリ要素 (prefix) が resolved_path で返される。

バグ

       この関数の POSIX.1-2001 版は、設計段階から問題がある。 出力バッファー resolved_path の適切
       なサイズを決定することができないからである。    POSIX.1-2001    ではバッファーサイズとして
       PATH_MAX は十分だとされているが、 PATH_MAX は定義済の定数である必要はなく、 pathconf(3) を
       使って得られる値であってもよいことになっている。 pathconf(3)  からバッファーサイズを取得し
       たとしても必ずしも十分ではない。 なぜなら、POSIX で警告されているように、 pathconf(3)   の
       返り値が大き過ぎて適切にメモリーを確保することができない  かもしれない一方で、 pathconf(3)
       は PATH_MAX に制限がないことを示す -1 を返すかもしれないからである。 resolved_path == NULL
       の機能を使うと、この設計上の問題を回避することができる。  この機能は POSIX.1-2001 では標準
       化されていないが、 POSIX.1-2008 では標準化されている。

関連項目

       realpath(1), readlink(2), canonicalize_file_name(3), getcwd(3), pathconf(3), sysconf(3)

この文書について

       この man ページは Linux man-pages プロジェクトのリリース 5.10 の一部である。プロジェクトの
       説明とバグ報告に関する情報は https://www.kernel.org/doc/man-pages/ に書かれている。

                                            2017-09-15                                REALPATH(3)