REALPATH(3) Linux Programmer's Manual REALPATH(3)
realpath - return the canonicalized absolute pathname
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
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
Otherwise it returns a NULL pointer, and the contents of the array
resolved_path are undefined. The global variable errno is set to indi-
cate the error.
EACCES Read or search permission was denied for a component of the path
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
A component of a pathname exceeded NAME_MAX characters, or an
entire pathname exceeded PATH_MAX characters.
ENOENT The named file does not exist.
A component of the path prefix is not a directory.
On Linux this function appeared in libc 4.5.21.
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
path_max = PATH_MAX;
path_max = pathconf(path, _PC_PATH_MAX);
if (path_max <= 0)
path_max = 4096;
(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 <unistd.h> in libc4
and libc5, but in <stdlib.h> everywhere else.
The glibc implementation of realpath() provides a non-standard exten-
sion. If resolved_path is specified as NULL, then realpath() uses mal-
loc(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 path-
conf(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 unsuit-
able 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(8) need a private
readlink(2), canonicalize_file_name(3), getcwd(3), pathconf(3),
This page is part of release 3.05 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/.