bug#44128: [feature/native-comp]

[Phil Sainty]

On 16/04/21 2:42 am, Eli Zaretskii wrote:
>> $ emacs --version
>> emacs: could not resolve realpath of "emacs": No such file or directory
>> $ touch emacs
>> $ emacs --version
>> emacs: 
>> /tmp/../native-lisp/28.0.50-abd7aa58/preloaded/window-0d1b8b93-581f9fcd.eln: 
>> cannot open shared object file: No such file or directory
>
> That's Emacs trying to see if it is run uninstalled, so I see no
> problem here.  What exactly do you think is wrong with this, again?

The first problem is that it's currently not possible to start
emacs if you're in a directory which contains a file or directory
called 'emacs'.  I think that's Bad, and it will undoubtedly be
reported as a bug by other people for as long as that persisted.
It certainly doesn't happen with non-native-comp builds.

The second problem is that this type of behaviour feels rather
like something you mentioned earlier: having "." in your PATH,
which is widely considered a bad idea.  I expect that exploits
are unlikely (e.g. arranging for a malicious
native-lisp/28.0.50-abd7aa58/preloaded/window-0d1b8b93-581f9fcd.eln
to exist is probably a lot of work), but I think Emacs should not
behave differently depending on where you are when you start it.

In future, once this feature is merged, many people will have
multiple local installs of various native-comp-enabled versions,
and might be moving between them and/or working on them.  If
Emacs then tried to run code for the version in the CWD even if
the executable that was invoked was for a different install, that
would be very surprising (and potentially very difficult for the
user to notice).

I do see the hashes in the filenames, so maybe that scenario is
already avoided, if the eln filenames are unique to the version
of Emacs?  This "looking in the CWD" behaviour still feels wrong
to me, though.  Are there other existing ways in which Emacs
changes its behaviour based on the CWD?


-Phil