リナックスコマンド

realpathのヘルプ・マニュアル

日本語 英語

• help
• man

realpath --help

man realpath

REALPATH(3) Linux Programmer’s Manual REALPATH(3) 名前 realpath - 正規化された絶対パス名を返す 書式 #include #include char *realpath(const char *path, char *resolved_path); glibc 向けの機能検査マクロの要件 (feature_test_macros(7) 参照): realpath(): _BSD_SOURCE || _XOPEN_SOURCE >= 500 説明 realpath() は path として与えられた NULL 終端された文字列中のすべてのシ ンボリックリンクを展開し、 /./, /../ による参照や余分な '/' を解決し て 、 正 規 化 さ れ た 絶対パス名を生成する。得られた絶対パス名は、最大で PATH_MAX バイトの NULL 終端された文字列として、 resolved_path により 参 照 されるバッファに格納される。結果として返るパスの中には、シンボリック リンクや /./, /../ といった要素は含まれない。 resolved_path に NULL が 指定されると、 realpath() は malloc(3) を使って解決したパス名を保持する ためのバッファを最大で PATH_MAX バイトまで割り当て、このバッファへの ポ インタを返す。呼び出し元は、 free(3) を使ってこのバッファを解放すべきで ある。 返り値 エラーがなかった場合、 realpath() は resolved_path へのポインターを返す 。 それ以外の場合は、ヌル (NULL) ポインターが返り、配列 resolved_path の内 容は不定である。グローバル変数 errno がエラーの内容にあわせてセットされ る。 エラー EACCES パスのディレクトリ部分に、読み出し許可または検索許可が与えられて いない。 EINVAL path か resolved_path のいずれかが NULL である。 (libc5 では、こ のような場合 segfault を起こすだけであろう) 但し、下記の「注意」 の節を参照のこと。 EIO ファイルシステムを読むときに、I/Oエラーが起こった。 ELOOP パス名の変換にあたり、解決すべきシンボリック・リンクの数が多過ぎ た。 ENAMETOOLONG パス名の一要素の文字数が NAME_MAX を越えている、またはパス名全体 の文字数が PATH_MAX を越えている。 ENOENT 指定されたファイルが存在しない。 ENOTDIR パスのディレクトリ要素が、ディレクトリでない。 バージョン この関数が Linux に登場したのは libc 4.5.21 である。 準拠 4.4BSD, POSIX.1-2001. POSIX.1 では resolved_path が NULL の場合の動作は実装に依存するとしてい る 。 POSIX.1-2008 では、このマニュアルページに書かれている動作が規定さ れている。 4.4BSD と Solaris では、パス名の長さの上限は ( の中にある) MAXPATHLEN である。SUSv2 では PATH_MAX と NAME_MAX が規定さ れており、これらは で定義されているか、 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 (バグの章も参照のこと。) 4.4BSD 、Linux、SUSv2 では、返り値は常に絶対パス名である。 Solaris では 、引き数 path が相対パスの場合、返り値が相対パスになるこ と が あ る 。 realpath() のプロトタイプ宣言は、 libc4 と libc5 では にある が、それ以外の環境ではいずれも にある。 バグ この関数の使用は避けること。設計段階から問題があるからだ。 (非 標 準 の resolved_path == NULL の 拡 張 機 能 を 使 わ な い限り) 出力バッファ resolved_path の適切なサイズを決定することができないからである。 POSIX で は バッファ・サイズとして PATH_MAX は十分だとされているが、 PATH_MAX は定義済の定数である必要はなく、 pathconf(3) を使って得られる値であって もよいことになっている。 pathconf(3) からバッファ・サイズを取得したとし ても必ずしも十分ではない。なぜなら、 pathconf(3) の返り値が大き過ぎて適 切にメモリを確保することができないかもしれないと POSIX では警告されてい るし、 pathconf(3) は PATH_MAX に制限がないことを示す -1 を返すかもしれ ないからである。 libc4 と libc5 の実装はバッファ・オーバーフローの可能性を持っている (libc-5.4.13 で修正されたが)。したがって、 mount(8) のような set-user- ID されるプログラムでは、この関数相当の関数を自前で持つ必要がある。 関連項目 readlink(2), canonicalize_file_name(3), getcwd(3), pathconf(3), sysconf(3) 2008-09-26 REALPATH(3)

REALPATH(3) Linux Programmer’s Manual REALPATH(3) NAME realpath - return the canonicalized absolute pathname SYNOPSIS #include #include char *realpath(const char *path, char *resolved_path); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): realpath(): _BSD_SOURCE || _XOPEN_SOURCE >= 500 DESCRIPTION realpath() expands all symbolic links and resolves references to /./, /../ and extra '/' characters in the null-terminated string named by path to produce a canonicalized absolute pathname. The resulting path- name is stored as a null-terminated string, up to a maximum of PATH_MAX bytes, in the buffer pointed to by resolved_path. The resulting path will have no symbolic link, /./ or /../ components. If resolved_path is specified as NULL, then realpath() uses malloc(3) to allocate a buffer of up to PATH_MAX bytes to hold the resolved path- name, and returns a pointer to this buffer. The caller should deallo- cate this buffer using free(3). RETURN VALUE If there is no error, realpath() returns a pointer to the resolved_path. Otherwise it returns a NULL pointer, and the contents of the array resolved_path are undefined, and errno is set to indicate the error. ERRORS EACCES Read or search permission was denied for a component of the path prefix. EINVAL Either path or resolved_path is NULL. (In libc5 this would just cause a segfault.) But, see NOTES below. EIO An I/O error occurred while reading from the file system. ELOOP Too many symbolic links were encountered in translating the pathname. ENAMETOOLONG A component of a pathname exceeded NAME_MAX characters, or an entire pathname exceeded PATH_MAX characters. ENOENT The named file does not exist. ENOTDIR A component of the path prefix is not a directory. VERSIONS On Linux this function appeared in libc 4.5.21. CONFORMING TO 4.4BSD, POSIX.1-2001. POSIX.1-2001 says that the behavior if resolved_path is NULL is imple- mentation-defined. POSIX.1-2008 specifies the behavior described in this page. NOTES In 4.4BSD and Solaris the limit on the pathname length is MAXPATHLEN (found in ). SUSv2 prescribes PATH_MAX and NAME_MAX, as found in or provided by the pathconf(3) function. A typical source fragment would be #ifdef PATH_MAX path_max = PATH_MAX; #else path_max = pathconf(path, _PC_PATH_MAX); if (path_max <= 0) path_max = 4096; #endif (But see the BUGS section.) The 4.4BSD, Linux and SUSv2 versions always return an absolute path- name. Solaris may return a relative pathname when the path argument is relative. The prototype of realpath() is given in in libc4 and libc5, but in everywhere else. BUGS The POSIX.1-2001 standard version of this function is broken by design, since it is impossible to determine a suitable size for the output buffer, resolved_path. According to POSIX.1-2001 a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(3). And asking pathconf(3) does not really help, since, on the one hand POSIX warns that the result of pathconf(3) may be huge and unsuitable for mallocing memory, and on the other hand pathconf(3) may return -1 to signify that PATH_MAX is not bounded. The resolved_path == NULL feature, not standardized in POSIX.1-2001, but standardized in POSIX.1-2008, allows this design problem to be avoided. The libc4 and libc5 implementation contains a buffer overflow (fixed in libc-5.4.13). Thus, set-user-ID programs like mount(8) need a private version. SEE ALSO readlink(2), canonicalize_file_name(3), getcwd(3), pathconf(3), sysconf(3) COLOPHON This page is part of release 3.22 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. 2009-02-23 REALPATH(3)