Re: Proposal: getexecpath(3)

Le 16/12/2024 à 23:45, Taylor R Campbell a écrit :
> PROPOSAL: New libc function
> 
> 	const char *getexecpath(void);
> 
> returns the pathname that was passed to execve(2), unmodified.
> 
> Thoughts?

Hey Taylor,

I welcome such an addition; I had to deal with a problem alike in a 
"portable" way (...), and that ended up in a painful and fragile way. I 
have some remarks though, low tier (not blocking/critical).

1 - As there is prior art elsewhere (getexecname(3)), unless there is a 
specific (legal?) reason not to have the same name, I would reuse it (or 
provide an alias) -- especially when obscure autotooling are looking for 
such a function;

2 - some shells like ksh(1) add the "_" environ parameter, and I have 
never seen or heard programs behaving badly because of it. So there is 
also prior art here -- but that implies a cooperative execve(2) caller, 
which is not quite in the present scope. I always wondered whether some 
programs used that functionality, but never encountered one (probable 
blindness here). Obviously this moves out the functionality from auxv to 
envp;

3 - (at least for Linux) /proc/self/file is shown as a symlink, but it 
is not really one. When the pointed file is removed (or disappeared, 
inaccessible, whatever), AFAIR we get something like "(removed/deleted)" 
appended; I expect a symlink to remain as-is. I understand the reason 
behind that choice, but it shows the limitations of such an approach, 
and how fragile this can become. I became wary of using readlink(2) 
results bluntly around /proc and /sys.

> 
> 
> DETAILS:
> 
> [snip]

Thanks,

-- 
jym@