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.
