Re: Proposal: getexecpath(3)

[Brad Smith <brad%comstyle.com@localhost>]

On Mon, Dec 16, 2024, Taylor R Campbell wrote:
> PROPOSAL: New libc function
>
>     const char *getexecpath(void);
>
> returns the pathname that was passed to execve(2), unmodified.

I know this is not quite what you are looking for, but FYI, OpenBSD
has since added a getexecpath(3) to libc, first appearing in
OpenBSD 8.0:

  https://man.openbsd.org/getexecpath.3

Unlike NetBSD, OpenBSD did not even have a sysctl like
KERN_PROC_PATHNAME to fall back on, so software was left guessing
from argv[0]. That said, after looking through many open source
projects, I see a lot of them have not been updated to use NetBSD's
sysctl either.

  #include <unistd.h>

  int
  getexecpath(char *buf, size_t bufsize);

It copies the absolute pathname of the executable into buf,
canonicalized the same way as realpath(3), and returns 0 on success
or -1 with errno set on failure (e.g. the executable was started in
a directory no longer linked into the filesystem, or the buffer is
too small; PATH_MAX is the recommended size).

The path is computed by the kernel in execve(2) and placed on the
new process's stack as an ELF auxiliary vector entry, which libc
picks up at startup. The relevant commits:

https://github.com/openbsd/src/commit/4dde6567f895c6faa36acbacd4cdf62954a70399
    In execve(2), attempt to create a realpath buffer for the
    executable and pass it to userland as an auxval

https://github.com/openbsd/src/commit/026846f111232f45cd1f4883414c190c8ff722a7
    Add getexecpath(3) to libc

https://github.com/openbsd/src/commit/1d46e5b94d0221c062218de40c6d15f9f5cacb31
    Make getexecpath() return the ELF executable that is running
    (for a script run via a shebang line, the canonicalized path of
    the interpreter actually executed)

So the name is the same, but both the signature and the semantics
differ from what is proposed here: a canonical absolute path rather
than the verbatim execve(2) argument. If NetBSD goes ahead with
this, it would be good to either match OpenBSD's interface or pick a
different name. Portable software is already starting to probe for
getexecpath() (HAVE_GETEXECPATH checks in configure/meson/CMake), and
two incompatible functions under the same name would be an
unpleasant trap.

On the consumer side, I have been adding getexecpath() support for
OpenBSD to quite a few common open source packages, Racket among
them, which uses the same kind of self-path logic that tripped up
lang/racket in your postscript. A compatible interface on NetBSD
would let the same code paths be reused.