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@