bug#12123:

bug#12123:

[chad]

Web searching suggests approaches for several specific platforms
(GNU/Linux, FreeBSD, Solaris, macosx, and Windows) that might be
useful:

http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

bug#12123:

[Glenn Morris]

chad wrote:

> Web searching suggests approaches for several specific platforms
> (GNU/Linux, FreeBSD, Solaris, macosx, and Windows) that might be
> useful:
>
> http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

I don't think this is an issue. We've already got invocation-directory,
which is probably good enough in 99.9+% of cases. Unless people do
obscure things to hide the executable, in which case they just don't get
to use a relocatable Emacs.

bug#12123:

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Fri, 5 Apr 2013 10:27:21 -0700
> 
> Web searching suggests approaches for several specific platforms
> (GNU/Linux, FreeBSD, Solaris, macosx, and Windows) that might be
> useful:
> 
> http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

The Windows method mentioned there is exactly what Emacs already uses
on Windows.

Anyway, I see that gnulib has a progreloc module whose purpose is to
make program relocatable.  Perhaps Paul (CC'ed) could import it and
use it in callproc.c to do what Stefan suggested.

bug#12123:

[Paul Eggert]

On 04/05/2013 10:48 AM, Eli Zaretskii wrote:
> Perhaps Paul (CC'ed) could import it and
> use it in callproc.c to do what Stefan suggested.

That sounds like it might work, yes, but it's
nontrivial.  I've never used that module myself.

bug#12123:

[Eli Zaretskii]

> Date: Fri, 05 Apr 2013 23:47:28 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: chad <yandros@MIT.EDU>, 12123@debbugs.gnu.org
> 
> On 04/05/2013 10:48 AM, Eli Zaretskii wrote:
> > Perhaps Paul (CC'ed) could import it and
> > use it in callproc.c to do what Stefan suggested.
> 
> That sounds like it might work, yes, but it's
> nontrivial.  I've never used that module myself.

Then perhaps we could just borrow the ideas from progreloc.c.

bug#12123:

[Paul Eggert]

On 04/06/2013 01:22 AM, Eli Zaretskii wrote:
> Then perhaps we could just borrow the ideas from progreloc.c.

That sounds like more work than using the Gnulib module,
I expect.

bug#12123:

[Eli Zaretskii]

> Date: Sat, 06 Apr 2013 13:35:09 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: yandros@MIT.EDU, 12123@debbugs.gnu.org
> 
> On 04/06/2013 01:22 AM, Eli Zaretskii wrote:
> > Then perhaps we could just borrow the ideas from progreloc.c.
> 
> That sounds like more work than using the Gnulib module,
> I expect.

Not necessarily.  progreloc.c is relatively short, and is really just
a series of platform-dependent methods to find the absolute file name
of the running program.  The MS-Windows method used there is already
being used in Emacs, and most of the infrastructure for relocating a
directory is already in place.

bug#12123:

[Glenn Morris]

Eli Zaretskii wrote:

>> > Then perhaps we could just borrow the ideas from progreloc.c.
>> 
>> That sounds like more work than using the Gnulib module,
>> I expect.
>
> Not necessarily.  progreloc.c is relatively short, and is really just
> a series of platform-dependent methods to find the absolute file name
> of the running program.  The MS-Windows method used there is already
> being used in Emacs, and most of the infrastructure for relocating a
> directory is already in place.

I must be missing something, because AFAICS, invocation-directory has
already solved this problem. What cases are not already handled that are
relevant and need extra code adding from progreloc.c?

bug#12123:

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  12123@debbugs.gnu.org,  yandros@MIT.EDU
> Date: Sun, 07 Apr 2013 14:32:51 -0400
> 
> I must be missing something, because AFAICS, invocation-directory has
> already solved this problem. What cases are not already handled that are
> relevant and need extra code adding from progreloc.c?

Code in emacs.c that sets invocation-directory relies on argv[0] to
either be an absolute file name, or relative to cwd, or a base name
without leading directories that can be found on PATH.  But on Posix
platforms, argv[0] can be anything, while on Windows argv[0] might be
neither absolute nor on PATH.

progreloc.c solves this in platform-specific ways.  E.g., on
GNU/Linux, it looks at /proc/PID/exe.

bug#12123:

[Eli Zaretskii]

> Date: Sun, 07 Apr 2013 22:06:32 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12123@debbugs.gnu.org, yandros@MIT.EDU, eggert@cs.ucla.edu
> 
> Code in emacs.c that sets invocation-directory relies on argv[0] to
> either be an absolute file name, or relative to cwd, or a base name
> without leading directories that can be found on PATH.

Btw, even if these conditions _are_ true, I still don't see how can we
find /usr/libexec/emacs/VERSION/CONFIG/, /usr/share/emacs/VERSION/lisp/
using the fact that Emacs was invoked from /usr/bin/.  Which part of
the code knows about VERSION and CONFIG part and looks for them?  All I
see is that we look for lib-src and etc, but that's only good to detect
that we are being run from the build directory, not from where we are
installed.  What am I missing?

bug#12123:

[Glenn Morris]

Eli Zaretskii wrote:

> Btw, even if these conditions _are_ true, I still don't see how can we
> find /usr/libexec/emacs/VERSION/CONFIG/, /usr/share/emacs/VERSION/lisp/
> using the fact that Emacs was invoked from /usr/bin/.  Which part of
> the code knows about VERSION and CONFIG part and looks for them?  All I
> see is that we look for lib-src and etc, but that's only good to detect
> that we are being run from the build directory, not from where we are
> installed.  What am I missing?

Well yes, that's the point of this report. No-one has implemented a
relocatable Emacs installation for general POSIX platforms. Solving
those problems is part of it. A relocatable Emacs would not be installed
as you describe above, it would (I imagine) be installed similar to the
way the NS build is, under a single top-level directory.

bug#12123:

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 12123@debbugs.gnu.org,  yandros@MIT.EDU,  eggert@cs.ucla.edu
> Date: Sun, 07 Apr 2013 22:00:49 -0400
> 
> Eli Zaretskii wrote:
> 
> > Btw, even if these conditions _are_ true, I still don't see how can we
> > find /usr/libexec/emacs/VERSION/CONFIG/, /usr/share/emacs/VERSION/lisp/
> > using the fact that Emacs was invoked from /usr/bin/.  Which part of
> > the code knows about VERSION and CONFIG part and looks for them?  All I
> > see is that we look for lib-src and etc, but that's only good to detect
> > that we are being run from the build directory, not from where we are
> > installed.  What am I missing?
> 
> Well yes, that's the point of this report. No-one has implemented a
> relocatable Emacs installation for general POSIX platforms. Solving
> those problems is part of it. A relocatable Emacs would not be installed
> as you describe above, it would (I imagine) be installed similar to the
> way the NS build is, under a single top-level directory.

The example above is still under a single top-level directory, called
'/usr' (a.k.a. ${prefix}).  Relocating just means changing ${prefix}
after Emacs was built.

bug#12123:

[Glenn Morris]

Eli Zaretskii wrote:

> Code in emacs.c that sets invocation-directory relies on argv[0] to
> either be an absolute file name, or relative to cwd, or a base name
> without leading directories that can be found on PATH.

As I said, I think this will cover 99.9+% of cases. Anyone trying to do
anything more obscure just doesn't get to use a relocatable Emacs, IMO.
But of course if you want a totally general solution, go ahead.