[TUHS] Also, relative to absolute pathnames?

[Clem Cole via TUHS]

On Fri, Jun 26, 2026 at 11:47 AM Warner Losh <imp at bsdimp.com> wrote:

>
> gcc does not include this in their runtime library, nor does clang.
>
Note: I have many sources on my mac, and did a "locate -i realpath"


gcc13.1.0 's pdp-11 crosscompiler has it for sure - although that is the
"Libiberty" implementation, which header comment says it is "Based on
gdb_realpath from GDB." It also seems to have #ifdefs for a number of
systems, including Windows.   It is also scattered in other places from the
GNU toolkit (which is in my tree via "brew"), and as I said, I found it in
a few places on Kirk's CDs, and it seems to be from the 1993-94 timeframe
[SCCS it was last modified 16-Feb-94].  The 4.4BSD-related version is
Keith's implementation, and he has a comment in both the header and the man
page noting that it is based on yet another implementation by Jan-Simon
Pedry.   His code and man page seem to match, and shows that it depends on
the system calls: chdir(2), close(2), fchdir(2), lstat(2), open(2), and
readlink(2), plus the library call getcwd(3).

They are library functions.  The only "systemish" dependency I can see from
any of the implementations I found on my Mac was that they usually needed
getwd(3) or getcwd(3), which are library calls.  Then some use the
equivalent of the opendir() call, which is also userspace/library, but
some, like Keith's, don't try to parse the directory, but open the file "."
as an anchor point, and call the OS and "walk" the pathname with calls to
chdir(2) .  He then used fchdir(2) with the fd from opening "." at the
beginning to get put back where he started.

The only possibly worrisome requirement for Keith's is the ability to open
"." and then later use that fd with the fchdir() call, but that is part of
POSIX.1, so I would expect on a modern system, you will be fine.

That said, I think Warren wants this for 2.11BSD, and I see a section 2 man
page for it on the 2.11BSD image I'm running on a RPi.  So I would expect
if you grab Keith's implementation from Kirk's Disk4   lib/libc/gen/*realpath*
and copy it to 2.11BSD, there is a high possibility of it "just working."



> This
> isnt' a runtime library thing, it's a libc thing. glibc has an
> implementation.
>
Rather (as I said originally), it is a POSIX.1 function, part of stdlib:
https://pubs.opengroup.org/onlinepubs/009696799/functions/realpath.html

The point being, the *sources* are likely with the rest of the stdlib
functions, and I would expect the binary to be stored in libc or its
dynamic library, as that is the traditional place, but POSIX does require
that.