Liam Hupfer writes: > I am not really advocating for reverting this. I don’t think Emacs > should assume ‘argv[0]’ is correlated to the executable file name. I > just want to write this down in proximity to the change that exposed it. > I will probably report to Emacs since the C is relatively new. I opened [bug#79064: native-lisp directory resolution shouldn’t depend on Emacs filename resolution via argv[0]​]. On second thought, though, I think we should consider reverting the change to ‘wrap-program’. [bug#73405: wrap-program should use the basename of $0 as arg0] does not describe why ‘cling’ was segfaulting, but I suspect it’s due to similar bad assumptions about argv[0] as the Emacs issue. I think wrappers should be as transparent as possible—however the user invokes a command should be preserved in argv[0], whether using a basename with PATH resolution or a relative or absolute filename. We shouldn’t coerce argv[0] to a basename when the wrapper wasn’t called that way. 99% of the time argv[0] is irrelevant, but the common case I’m considering is programs that log how they were called—it’s disorienting for the wrapper to affect that. Maybe we can expose an argument to wrap-program to use the basename approach, but IMO we should be handling the root cause in cases where problems occur and pushing upstreams to handle arbitrary argv[0] values robustly. WDYT? Thanks! —Liam [bug#79064: native-lisp directory resolution shouldn’t depend on Emacs filename resolution via argv[0]​] [bug#73405: wrap-program should use the basename of $0 as arg0]