GNU bug report logs - #7793
inconsistent behavior of exec-path

Previous Next

Package: emacs;

Reported by: Sam Steingold <sds <at> gnu.org>

Date: Wed, 5 Jan 2011 23:03:01 UTC

Severity: normal

Tags: notabug, wontfix

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sam Steingold <sds <at> gnu.org>
Cc: 7793 <at> debbugs.gnu.org
Subject: Re: bug#7793: inconsistent behavior of exec-path
Date: Thu, 06 Jan 2011 05:10:33 -0500
> Date: Wed, 5 Jan 2011 18:07:48 -0500
> From: Sam Steingold <sds <at> gnu.org>
> Cc: 
> 
> suppose you have two directories (A&B) which contain two different
> executables with the same name (N).
> e.g., find.exe(N) in both "c:/gnu/gnuwin32/bin"(A) and "c:/WINDOWS/system32"(B).
> if A follows B in $PATH, then M-x shell-command will call A/N for N
> even if I manually swap A & B in exec-path.

You mean "iff", not "even if", right?  Because if you do _not_ swap A
and B in exec-path, I'd expect B/N to be invoked, since B precedes A
in PATH.  Am I missing something?

> However, if I run rgrep in "emacs -q", it fails because by default B
> is before A in PATH and exec-path;
> while if I push A to the beginning of exec-path before the first
> invocation of rgrep, rgrep will find and use the good N.

I used to play such games with PATH and exec-path (and a few other
related variables) inside Emacs, but then I grew older and wiser.
Please consider taking advice of my gray hair: don't do that.  Do
_not_ have values of PATH, exec-path, process-environment, etc. that
have the same directories in different order.  That way lies madness,
believe me.  The reason for this is very basic, on Windows as on Unix:
exec-path is used only for the program that Emacs invokes directly.
If that program invokes other programs, it will look them up on PATH.
So having conflicting orders in PATH and exec-path means that programs
invoked through call-process and programs invoked through
shell-command will be searched for using different order of
directories.  To get deterministic behavior out of this, you'd need to
know, for every Emacs command, whether it uses the former or the
latter, and even if you do, I don't think you will be able to set both
PATH and exec-path correctly for all your use-cases (including all the
bugs, misfeatures, and subtle incompatibilities of the Windows ports
of GNU software).

FWIW, I don't think the inconsistency that is the subject of this bug
can be resolved in any reasonable way.  The separation between
exec-path and PATH is deliberate in Emacs, so setting one from the
other will not DTRT at least for some use-cases.

> this inconsistency is bad and together with bugs
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6784
> and
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7785
> is causing me much grief in my first encounter with windows in 4 years.

I'm sorry about your trouble.  To save some of it in the future, I'd
suggest:

 . Put the GnuWin32 directory _before_ the Windows directories in PATH
 . If you need to use Cygwin executables in the same session as
   GnuWin32, decide on the order between them according to your needs;
   if you only use one or the other, throw together a bunch of batch
   files that reorder PATH for each one, and invoke the one you need
   when you need it (you can have a separate setting in each shell
   window)
 . Don't reshuffle exec-path and process-environment in your .emacs
 . If needed, and only as a last resort (if PATH reordering doesn't
   help), rename a few ported programs (e.g. find->gfind or
   date->gdate), so that Windows versions don't come in the way (you
   may need to customize a few variables if you do this,
   e.g. find-program for "gfind")

I find this arrangement to be a much saner one, and it works very well
for me for years.




This bug report was last modified 13 years and 170 days ago.

Previous Next


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