realpath — return the canonicalized absolute pathname
#include <limits.h> #include <stdlib.h>
char
*realpath( |
const char * | path, |
char * | resolved_path) ; |
realpath
() expands all
symbolic links and resolves references to '/./'
, '/../'
and extra '/'
characters in the null
terminated string named by path
and stores the
canonicalized absolute pathname in the buffer of size
PATH_MAX
named by resolved_path
. The resulting
path will have no symbolic link, '/./'
or '/../'
components.
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.
The global variable errno
is set
to indicate the error.
Read or search permission was denied for a component of the path prefix.
Either path
or resolved_path
is NULL.
(In libc5 this would just cause a segfault.) But, see
NOTES below.
An I/O error occurred while reading from the file system.
Too many symbolic links were encountered in translating the pathname.
A component of a pathname exceeded NAME_MAX
characters, or an entire
pathname exceeded PATH_MAX
characters.
The named file does not exist.
A component of the path prefix is not a directory.
4.4BSD, POSIX.1-2001.
In 4.4BSD and Solaris the limit on the pathname length is
MAXPATHLEN
(found in <sys/param.h>
). SUSv2
prescribes PATH_MAX
and
NAME_MAX
, as found in
<limits.h>
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 pathname. Solaris may return a relative pathname
when the path
argument is relative. The prototype of realpath
() is given in <unistd.h>
in libc4 and
libc5, but in <stdlib.h>
everywhere
else.
The glibc implementation of realpath
() provides a non-standard
extension. 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 pathname, and returns a pointer to this
buffer. The caller should deallocate this buffer using
free(3).
Avoid using this function. It is broken by design since
(unless using the non-standard resolved_path == NULL feature) it
is impossible to determine a suitable size for the output
buffer, resolved_path
. According to
POSIX 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 libc4 and libc5 implementation contains a buffer overflow (fixed in libc-5.4.13). Thus, set-user-ID programs like mount need a private version.
readlink(2), canonicalize_file_name(3), getcwd(3), pathconf(3), sysconf(3)
|