> Date: Sat, 4 Jan 2025 10:22:01 +0000 > From: David Holland <dholland-t...@netbsd.org> > > 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.
