Re: Finding the dump

["Daniel Colascione" <dancol@dancol.org>]

> Daniel Colascione wrote:
>> we_already_  do the moral equivalent of realpath(argv[0]), in
>> init_cmdargs, which sets invocation-directory and from there various
>> internal paths, including installation-directory.
>
> Emacs can run without any of that stuff, so people can run Emacs 26 with
> argv[0]
> being any string they like. That will stop working if Emacs can't run when
> argv[0] is "wrong".

Emacs can run with a wrong argv[0] if it's installed in its final
location, since we use the installation prefix as a fallback path. Nobody
is arguing that we should remove this feature. We're talking about what we
should do in the case that somebody is running an uninstalled Emacs, and
in this case, an executable-relative search *is* standard practice.

> The GNU Coding Standards have long said that a program's behavior
> shouldn't
> depend its name (i.e., on the contents of argv[0]),

Yet the original GNU program, Emacs, until just now, behaved differently
if it was called temacs. :-)

Anyway, I generally agree that program behavior shouldn't change depending
on its name --- that's why I changed how temacs works --- but finding the
location of the program doesn't count as "behavior". Emacs doesn't care
whether you call it "emacs", "trogdor", or "vim" so long as it can find
"lib-src", "info", and "etc" relative to wherever the binary happens to
be.

> and there are
> advantages to
> sticking to standard practices even if some programs depart from them.

I agree that we should stick to standard practice. That's why we should
continue looking at argv[0] to find Emacs-internal files in uninstalled
Emacs. We have some bugs that make this not quit work today: in order to
successfully run an uninstalled Emacs, you need to 1) have the correct
argv[0], _and_ 2) keep Emacs in its build location. It's #2 that's the
bug, not #1.