Inferior process mystery

Inferior process mystery

[Dave Abrahams]

Any of the following will launch /opt/local/bin/python, which is in my
PATH:

 * `M-! python RET'
 * `M-! python& RET'
 * `M-x shell RET python RET'
 * `C-u M-x run-python RET env python RET'

However, although the variable `python-command' has the value "python",
either of these will launch /usr/bin/python:

 * `M-x run-python'
 * `C-u M-x run-python RET python RET'

I'm at a loss to explain why python-command is not selecting the same
Python that's in my PATH and run by env.  Can someone explain why this
is happening?

Many thanks in advance,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Inferior process mystery

[Andreas Schwab]

What's your exec-path?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Inferior process mystery

[Dave Abrahams]

Yep, that is in fact the problem.  But how do I discover what is changing my exec-path?

,----[ C-h v exec-path RET ]
| exec-path is a variable defined in `callproc.c'.
| Its value is
| (nil "/usr/X11/bin/" "/sbin/" "/usr/sbin/" "/bin/" "/usr/bin/" "/Users/dave/src/git-submodule-tools/" "/opt/local/sbin/" "/opt/local/bin/" "/usr/local/sbin/" "/usr/local/git/bin/" "/usr/local/bin/" "/Users/dave/bin/git-scripts/" "/Users/dave/bin/" "/Users/dave/bin" "/Users/dave/bin/git-scripts" "/usr/local/bin" "/usr/local/git/bin" "/usr/local/sbin" "/opt/local/bin" "/opt/local/sbin" "/Users/dave/src/git-submodule-tools" "/usr/bin" "/bin" "/usr/sbin" "/sbin" "/usr/X11/bin" "." "/opt/local/libexec/emacs/24.0.94/x86_64-apple-darwin11.3.0")
| 
| Original value was 
| ("/opt/local/bin" "/opt/local/sbin" "/bin" "/sbin" "/usr/bin" "/usr/sbin" "/opt/local/var/macports/build/_Users_dave_Public_MacPorts_Portfiles_editors_emacs24-macport/emacs24-macport/work/emacs-24.0.94/lib-src" "/opt/local/libexec/emacs/24.0.94/x86_64-apple-darwin11.3.0")
| 
| 
|   This variable is potentially risky when used as a file local variable.
| 
| Documentation:
| *List of directories to search programs to run in subprocesses.
| Each element is a string (directory name) or nil (try default directory).
| 
| You can customize this variable.
| 
| [back]
`----


on Wed Apr 25 2012, Andreas Schwab <schwab-AT-linux-m68k.org> wrote:

> What's your exec-path?
>
> Andreas.


on Wed Apr 25 2012, Stefan Monnier <monnier-AT-iro.umontreal.ca> wrote:

> Could it be that your PATH and your `exec-path' don't hold the same list
> of directories?
>
>         Stefan

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Inferior process mystery

[Andreas Schwab]

Dave Abrahams <dave@boostpro.com> writes:

> Yep, that is in fact the problem.  But how do I discover what is changing my exec-path?

exec-path is initialized from $PATH as inherited by emacs, which appears
to be different from the one set in your shell.

> | Original value was 
> | ("/opt/local/bin" "/opt/local/sbin" "/bin" "/sbin" "/usr/bin" "/usr/sbin" "/opt/local/var/macports/build/_Users_dave_Public_MacPorts_Portfiles_editors_emacs24-macport/emacs24-macport/work/emacs-24.0.94/lib-src" "/opt/local/libexec/emacs/24.0.94/x86_64-apple-darwin11.3.0")

This value was set during dumping, and is not very useful as the
standard value of exec-path.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Inferior process mystery

[Ivan Andrus]

On Apr 25, 2012, at 8:02 PM, Andreas Schwab wrote:
> Dave Abrahams <dave@boostpro.com> writes:
> 
>> Yep, that is in fact the problem.  But how do I discover what is changing my exec-path?
> 
> exec-path is initialized from $PATH as inherited by emacs, which appears
> to be different from the one set in your shell.

Since you're on a Mac, GUI applications don't inherit from your shell.  Instead you should set environment variables in ~/.MacOSX/environment.plist, or see [1] for a number of other ways to set them and the different problems they have.

There are various ways to "fix" this automatically.  The method I use is to update environment.plist if .bashrc is newer [2].  Other methods include setting exec-path by calling a shell-script which will inherit your .bashrc setting.

This is a huge source of confusion and questions in places like StackOverflow.  I've been trying to think of a good way to bring this to people's attention without being obnoxious.  One idea is when, for example, a compilation buffer get's a command not found error, create an overlay (only on OS X (or perhaps not since it can happen in other desktop environments as well)) which explains the problem.  It wouldn't always apply of course, but it might save people some headaches.  I'm not sure if that sort of thing would be acceptable for inclusion in Emacs, but I think it would only be useful if it were on by default.

-Ivan

[1] http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x
[2] http://use.perl.org/~brian_d_foy/journal/8915

Re: Inferior process mystery

[John Wiegley]

>>>>> Ivan Andrus <darthandrus@gmail.com> writes:

> Since you're on a Mac, GUI applications don't inherit from your shell.
> Instead you should set environment variables in ~/.MacOSX/environment.plist,
> or see [1] for a number of other ways to set them and the different problems
> they have.

I use ~/.MacOSX/environment for _all_ environment variables, and then put this
in my .zshrc:

  if [ -x $HOME/bin/shell-args ]; then
    eval `$HOME/bin/shell-args`
  if

And that script does this:

  #!/usr/bin/perl
  
  $MULTILINE_MATCHING = 1;
  
  open(ARGS, "~/.MacOSX/environment.plist") || die;
  
  while (<ARGS>) {
      print "export $1" if /<key>(.+?)<\/key>/;
      print "=\"$1\"\n" if /<string>(.+?)<\/string>/;
  }

That way, I only have to consider a single place.

John

Re: Inferior process mystery

[Dave Abrahams]

on Wed Apr 25 2012, Andreas Schwab <schwab-AT-linux-m68k.org> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> Yep, that is in fact the problem.  But how do I discover what is changing my exec-path?
>
> exec-path is initialized from $PATH as inherited by emacs, which appears
> to be different from the one set in your shell.

Yeah, but if I start up with -Q I get something much more reasonable, so
what I need to know is what in my init sequence is munging it.

>> | Original value was 
>> | ("/opt/local/bin" "/opt/local/sbin" "/bin" "/sbin" "/usr/bin"
>> | "/usr/sbin"
>> | "/opt/local/var/macports/build/_Users_dave_Public_MacPorts_Portfiles_editors_emacs24-macport/emacs24-macport/work/emacs-24.0.94/lib-src"
>> | "/opt/local/libexec/emacs/24.0.94/x86_64-apple-darwin11.3.0")
>
> This value was set during dumping, and is not very useful as the
> standard value of exec-path.

Actually that would have been a pretty reasonable value.  My problem is
that my exec-path is out-of-control, and I don't know why.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Inferior process mystery

[Stefan Monnier]

> Any of the following will launch /opt/local/bin/python, which is in my
> PATH:

>  * `M-! python RET'
>  * `M-! python& RET'
>  * `M-x shell RET python RET'
>  * `C-u M-x run-python RET env python RET'

> However, although the variable `python-command' has the value "python",
> either of these will launch /usr/bin/python:

>  * `M-x run-python'
>  * `C-u M-x run-python RET python RET'

> I'm at a loss to explain why python-command is not selecting the same
> Python that's in my PATH and run by env.  Can someone explain why this
> is happening?

Could it be that your PATH and your `exec-path' don't hold the same list
of directories?


        Stefan