[TUHS] Also, relative to absolute pathnames?

[Warner Losh via TUHS]

On Fri, Jun 26, 2026 at 11:00 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> 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).
>

Yes. This is the version that gets it almost right, so would be easily
portable w/o the kernel assist. The dysfunction is around abuse of
hardlinks...


> 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.
>

Yes. Though on Linux you need to add O_DIRECTORY to do that. On FreeBSD you
can open the directory, but read(2) returns an error.


> 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."
>

Yes. Most of 2.11BSD is 4.2 with most of 4.3 and some 4.4 pulled in. I
agree it should be close to working there.


>
>
>> 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.
>

Yea. putting them in libc is the right call.  I've spent too much time
dealing with the subtle differences between a runtime library for a
compiler (which has routines and support for code generated by the compiler
like division on old arm parts) and libc (which has runtime support and
often system calls), so I can get wrapped around terminology too easily...

Warner