Re: Proposal: getexecpath(3)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sat, 4 Jan 2025 10:22:01 +0000
> From: David Holland <dholland-tech%netbsd.org@localhost>
> 
> On Sat, Jan 04, 2025 at 06:52:38AM +0000, Taylor R Campbell wrote:
>  > The point here is to grant the callee access to the exec path
>  > _without_ cooperation by the caller.
>  > 
>  > That way, the callee can find data files or libraries relative to
>  > where it was found, without requiring the caller to pass paths to
>  > those data files and libraries on the command line.
>  > 
>  > If the caller could be adapted to pass those paths, there would be no
>  > need for any of this.
> 
> Under normal circumstances the callee can use argv[0], though
> admittedly it's a bit of a nuisance since it requires examining $PATH
> if there's no / in the string. One could certainly make a library
> function that does that though.

execve(2) doesn't involve $PATH search, so even if you search $PATH
for argv[0], the result may not reflect the path that was passed to
execve(2).

> (IOW, I've never really understood the motivation for any of this
> stuff.)

Would like to volunteer to go through the dozens of packages in pkgsrc
that have patches involving KERN_PROC_PATHNAME or /proc/self/exe or
similar to disabuse them of their motivation for this stuff?

I'm just proposing a simpler API with clearer semantics to do it --
there isn't anything fundamentally new in this proposal.

I suspect that upstreaming patches that make a simple API call with
clearer semantics will be easier than dealing with the
KERN_PROC_PATHNAME mess (and its bizarre incompatibility with FreeBSD)
or convincing upstreams that they're wrong to want to ask the question
in the first place.