Re: Finding the dump (redux)

[Ali Bahrami]

Hi Eli,

   Thanks for giving your time on a Saturday to
look at this.

On 4/17/21 12:45 PM, Eli Zaretskii wrote:
> > From: Ali Bahrami <ali_gnu2@emvision.com>
> > I can solve this without changing emacs, superficially, by just
> > adding a corresponding mediator symlink for emacs.pdmp in the
> > PATH_EXEC directory. But then, if an end user were to make their
> > own symlink to one of these emacs variants, they'll still face
> > this problem:
> >
> >        % ln -s /usr/bin/emacs-gtk ~/bin/myemacs
>
> Why can't you put the *.pdmp files in the same directory where you
> keep the emacs-* executables (/usr/bin, AFAIU)?  That is already
> supported by the current code, I think.

I know the current code does support that, but it doesn't fit the
long lived rules we have for what belongs in /usr/bin. For something to
be in /usr/bin, it needs to be directly executable by the end user, and
of general utility. Anything else, including private helper executables,
go into an application specific area, usually under /usr/lib, so using
PATH_EXEC for this is a better fit.

The question is bigger than emacs. It dilutes the meaning of
/usr/bin if it starts collecting other types of files, and
we'd like to hold that line if we can.

A related idea that's been floated before would be for the
executable to carry the default dump data within itself. That
would also work (effectively like unexec did), but I'm
99% happy with the current scheme, and not looking for
that sort of big change.

> But realpath(argv[0]) can produce to a file in another directory,
> because realpath expands all the symlinks, not just that of the
> basename.  Does it make sense to look up the .pdmp file in the
> directory of the original argv[0] when it is a symlink?

It's an interesting question, and I think can be argued
either way.

It's simple to say "no", and I doubt it would bother many
users. In that case, we'd stat the argv[0], and if it's a
symlink, we'd just switch the existing PATH_EXEC code to
use the "real" basename. That would work for my purposes,
but I had imagined that it was written as it is for some
purpose, perhaps as a way to provide options for using
other pdmp files (see below), so I was trying not to change
those aspects, just to augment them.

I can imagine a scenario where it might be useful to
say "yes". It might offer a pretty slick way for end users
to create arbitrary pdmp files and associate them to specific
purposes. Suppose for instance that I want to use a special 'X'
dump file when working on "Project X" code. I could create a special
name for that emacs variant as a symlink to the basic emacs-gtk
in my personal bin:

   % ln -s /usr/bin/emacs-gtk ~/bin/emacsX

Then, if I were to create ~/bin/emacsX.pdmp, and if emacs were
willing to see it as a pdmp file to be loaded, then I could
run my special emacsX, and get the standard emacs (from the
symlink) using my specialized X pdmp.

There are other ways to solve this (shell scripts, shell
aliases, typing an option on the emacs command line), so I
don't know how important this is, but it does offer a pretty
simple way to get that effect.  If we did want this, my patch
checks the 2 names in the wrong order for it to work, so we
should flip them to check the "given" name first, and then the
"real" one.

The reverse question is, what harm does it do to look in PATH_EXEC
for both names? PATH_EXEC is a controlled namespace, laid out by
the emacs install package, so there's little risk of a name collision
with user named dump files. We should never reach the point of looking
in PATH_EXEC unless we've already failed to find a user specified pdmp
file, and are looking for the default one. It seems harmless to look
for both names at that point.

> >        - Move the repeated code into functions, to clean up load_pdump().
> >
> >        - Save the basename from the result of calling realpath() during the
> >          search of the executable directory.
> >
> >        - During the PATH_EXEC stage, use the saved realpath basename to
> >          add a check for that name.
>
> This is not enough, if we want to support *.pdmp files that have
> arbitrary names.  For example, when Emacs is invoked as "../emacs" (or
> any other relative file name which includes slashes), we currently
> don't expand symlinks, so with your proposal "emacs" and "../emacs"
> will behave differently.

I'm not sure I understand. I have the proposed bits installed
on my desktop right now, and this does work as I expect.

    % cd /usr/bin
    % ../bin/emacs

As does

    % emacs

I can tell in both cases that the emacs-gtk.pdmp from
PATH_EXEC was loaded. It does seem to be solving the
problem I set out to fix.

I don't see any code in load_pdump() that special cases
the case that includes slashes --- it seems like realpath()
is always called, so perhaps I might not be understanding your
point correctly.


> IOW, supporting arbitrarily-named *.pdmp files requires more thorough
> revision of the logic in load_pdump than just some simple refactoring.
> Especially as Emacs 28 will have the native-compilation feature,
> whereby it also needs to find at startup the directory with the *.eln
> files that correspond to the preloaded Lisp files; see bug#44128.

I think you're right that the above isn't enough for arbitrary names,
but it's not trying to be. As long as it doesn't interfere with that
later effort, there shouldn't be a conflict. My goal is just to make
sure that out of the box default behavior works, without the sort of
mysterious failure (to a naive user) that symlinks cause today. I would
expect processing arbitrary pdmp files would happen before we reached the
stage of looking for the default pdmp files in PATH_EXEC, and that
if arbitrary files were seen, that we either won't look in PATH_EXEC
at all, or that we can look with modified logic that make sense for
that case.

- Ali