all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Sam Steingold <sds@gnu.org>
Cc: 7793@debbugs.gnu.org
Subject: bug#7793: inconsistent behavior of exec-path
Date: Thu, 06 Jan 2011 05:10:33 -0500	[thread overview]
Message-ID: <E1Pamnh-0008P2-Io@fencepost.gnu.org> (raw)
In-Reply-To: <AANLkTikAPjQW0Nn5EvD-WnG=7rYy6F=n=Cf8i1Cgd1m6@mail.gmail.com> (message from Sam Steingold on Wed, 5 Jan 2011 18:07:48 -0500)

> Date: Wed, 5 Jan 2011 18:07:48 -0500
> From: Sam Steingold <sds@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.





  reply	other threads:[~2011-01-06 10:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 23:07 bug#7793: inconsistent behavior of exec-path Sam Steingold
2011-01-06 10:10 ` Eli Zaretskii [this message]
2012-02-03 22:31   ` Glenn Morris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1Pamnh-0008P2-Io@fencepost.gnu.org \
    --to=eliz@gnu.org \
    --cc=7793@debbugs.gnu.org \
    --cc=sds@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.