unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#12123:
       [not found] <probmtut73.fsf@fencepost.gnu.org>
@ 2013-04-05 17:27 ` chad
  2013-04-05 17:32   ` bug#12123: Glenn Morris
  2013-04-05 17:48   ` bug#12123: Eli Zaretskii
  0 siblings, 2 replies; 13+ messages in thread
From: chad @ 2013-04-05 17:27 UTC (permalink / raw)
  To: 12123

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-05 17:27 ` bug#12123: chad
@ 2013-04-05 17:32   ` Glenn Morris
  2013-04-05 17:48   ` bug#12123: Eli Zaretskii
  1 sibling, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2013-04-05 17:32 UTC (permalink / raw)
  To: 12123

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-05 17:27 ` bug#12123: chad
  2013-04-05 17:32   ` bug#12123: Glenn Morris
@ 2013-04-05 17:48   ` Eli Zaretskii
  2013-04-06  6:47     ` bug#12123: Paul Eggert
  1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-05 17:48 UTC (permalink / raw)
  To: chad, Paul Eggert; +Cc: 12123

> 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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-05 17:48   ` bug#12123: Eli Zaretskii
@ 2013-04-06  6:47     ` Paul Eggert
  2013-04-06  8:22       ` bug#12123: Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Paul Eggert @ 2013-04-06  6:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 12123, chad

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-06  6:47     ` bug#12123: Paul Eggert
@ 2013-04-06  8:22       ` Eli Zaretskii
  2013-04-06 20:35         ` bug#12123: Paul Eggert
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-06  8:22 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 12123, yandros

> 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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-06  8:22       ` bug#12123: Eli Zaretskii
@ 2013-04-06 20:35         ` Paul Eggert
  2013-04-07  2:42           ` bug#12123: Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Paul Eggert @ 2013-04-06 20:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 12123, yandros

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.






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-06 20:35         ` bug#12123: Paul Eggert
@ 2013-04-07  2:42           ` Eli Zaretskii
  2013-04-07 18:32             ` bug#12123: Glenn Morris
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-07  2:42 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 12123, yandros

> 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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-07  2:42           ` bug#12123: Eli Zaretskii
@ 2013-04-07 18:32             ` Glenn Morris
  2013-04-07 19:06               ` bug#12123: Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2013-04-07 18:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 12123, yandros, Paul Eggert

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?





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-07 18:32             ` bug#12123: Glenn Morris
@ 2013-04-07 19:06               ` Eli Zaretskii
  2013-04-07 19:42                 ` bug#12123: Eli Zaretskii
  2013-04-08  2:02                 ` bug#12123: Glenn Morris
  0 siblings, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-07 19:06 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 12123, yandros, eggert

> 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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-07 19:06               ` bug#12123: Eli Zaretskii
@ 2013-04-07 19:42                 ` Eli Zaretskii
  2013-04-08  2:00                   ` bug#12123: Glenn Morris
  2013-04-08  2:02                 ` bug#12123: Glenn Morris
  1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-07 19:42 UTC (permalink / raw)
  To: rgm; +Cc: 12123, yandros, eggert

> 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?





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-07 19:42                 ` bug#12123: Eli Zaretskii
@ 2013-04-08  2:00                   ` Glenn Morris
  2013-04-08  2:44                     ` bug#12123: Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2013-04-08  2:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 12123, yandros, eggert

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-07 19:06               ` bug#12123: Eli Zaretskii
  2013-04-07 19:42                 ` bug#12123: Eli Zaretskii
@ 2013-04-08  2:02                 ` Glenn Morris
  1 sibling, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2013-04-08  2:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 12123, yandros, eggert

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#12123:
  2013-04-08  2:00                   ` bug#12123: Glenn Morris
@ 2013-04-08  2:44                     ` Eli Zaretskii
  0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-04-08  2:44 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 12123, yandros, eggert

> 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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2013-04-08  2:44 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <probmtut73.fsf@fencepost.gnu.org>
2013-04-05 17:27 ` bug#12123: chad
2013-04-05 17:32   ` bug#12123: Glenn Morris
2013-04-05 17:48   ` bug#12123: Eli Zaretskii
2013-04-06  6:47     ` bug#12123: Paul Eggert
2013-04-06  8:22       ` bug#12123: Eli Zaretskii
2013-04-06 20:35         ` bug#12123: Paul Eggert
2013-04-07  2:42           ` bug#12123: Eli Zaretskii
2013-04-07 18:32             ` bug#12123: Glenn Morris
2013-04-07 19:06               ` bug#12123: Eli Zaretskii
2013-04-07 19:42                 ` bug#12123: Eli Zaretskii
2013-04-08  2:00                   ` bug#12123: Glenn Morris
2013-04-08  2:44                     ` bug#12123: Eli Zaretskii
2013-04-08  2:02                 ` bug#12123: Glenn Morris

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).