GNU bug report logs - #44128
[feature/native-comp]; When invoking a symlink to the 'emacs' binary Emacs fails to start

Previous Next

Full log

Message #61 received at 44128 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jonas <at> bernoul.li, 44128 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#44128: [feature/native-comp]
Date: Sat, 17 Apr 2021 00:04:12 +1200

On 16/04/21 6:50 pm, Eli Zaretskii wrote:
>> 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'.
> 
> That's not relevant to the message above; the failure related to the
> presence of a directory or file named 'emacs' is a bug that will be
> solved.

Ok, I misinterpreted your question.


>> 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.
> 
> But that ship has sailed long, long, LONG ago: Emacs was always
> looking for its Lisp files in the directory "../lisp" relative to
> where it was invoked since about forever.  How else can we support
> both installed and uninstalled invocations?  When Emacs is run
> uninstalled, the Lisp files can be anywhere on the system.  The only
> difference is that now we _also_ look for the *.eln files in a similar
> fashion.

For clarity, by the directory "where it was invoked" do you mean
the arbitrary directory from which the user runs "emacs", or do
you mean the directory containing the (real) emacs executable?

If you mean the latter, then I don't see a problem.

If you mean the former, then...

If we are able to successfully establish where the (real) emacs
executable is (and your recent patch looked like it achieved this),
then surely that can account for the "uninstalled invocations"
cases as well?  (Because we know where to find all of the
uninstalled paths of interest relative to the uninstalled
executable.)

My only concern is that looking for particular filenames in the
user's arbitrary CWD will be prone to false-positives; so if this
*is* happening, and there's a better solution at hand, perhaps
there's no longer any need to do it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.