Re: Proposal: getexecpath(3)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jan 04, 2025 at 10:45:11AM +0000, Taylor R Campbell wrote:
 > > 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).

That's true, but under normal circumstances if the user ran "foo" from
the current directory argv[0] will contain "./foo".

This is a matter of the conventions of shells, not guarantees of
anything, but the conventions are strong enough to use for these
purposes. Except for setugid bins. (And, traditionally, login shells.)

Well, and it doesn't work if you run things via links, but ultimately
none of these schemes do.

 > > (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?

That's what I don't understand the motivation for.

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

That's probably true.

Although I wonder if anyone would notice if we provided a method that
used argv[0] :-)

-- 
David A. Holland
dholland%netbsd.org@localhost