purcell / exec-path-from-shell

Make Emacs use the $PATH set up by the user's shell
Other
1.41k stars 81 forks source link

PATH seems different in GUI, -nw, and shells. #112

Closed theherk closed 1 year ago

theherk commented 1 year ago

I don't think I understand how this works, but I seem to have an issue on MacOS since switching my default shell to fish. I initialize with

(when (memq window-system '(mac ns x))
  (exec-path-from-shell-initialize))

My understanding is, that my environment should be copied into the emacs gui, but no joy.

fish > echo $PATH
/opt/homebrew/Cellar/pyenv-virtualenv/1.2.1/shims /Users/h4s/.pyenv/shims /opt/homebrew/bin /opt/homebrew/sbin /opt/homebrew/opt/coreutils/libexec/gnubin /Users/h4s/bin /Users/h4s/.emacs.d/bin /Users/h4s/projects/go/bin /Users/h4s/.cargo/bin /usr/local/bin /System/Cryptexes/App/usr/bin /usr/bin /bin /usr/sbin /sbin /usr/local/go/bin /Library/TeX/texbin

zsh > echo $PATH
/opt/homebrew/Cellar/pyenv-virtualenv/1.2.1/shims:/Users/h4s/.pyenv/shims:/opt/homebrew/Cellar/pyenv-virtualenv/1.2.1/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/opt/coreutils/libexec/gnubin:/Users/h4s/bin:/Users/h4s/.emacs.d/bin:/Users/h4s/projects/go/bin:/Users/h4s/.cargo/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Library/TeX/texbin

sh > echo $PATH
/opt/homebrew/Cellar/pyenv-virtualenv/1.2.1/shims:/Users/h4s/.pyenv/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/opt/coreutils/libexec/gnubin:/Users/h4s/bin:/Users/h4s/.emacs.d/bin:/Users/h4s/projects/go/bin:/Users/h4s/.cargo/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Library/TeX/texbin

getenv PATH in emacs -nw:

/opt/homebrew/Cellar/pyenv-virtualenv/1.2.1/shims:/Users/h4s/.pyenv/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/opt/coreutils/libexec/gnubin:/Users/h4s/bin:/Users/h4s/.emacs.d/bin:/Users/h4s/projects/go/bin:/Users/h4s/.cargo/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Library/TeX/texbin

getenv PATH in emacs gui:

/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Library/TeX/texbin:/Users/h4s/.emacs.d/bin:/opt/homebrew/Cellar/pyenv-virtualenv/1.2.1/shims:/Users/h4s/.pyenv/shims:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/homebrew/opt/coreutils/libexec/gnubin:/Users/h4s/bin:/Users/h4s/projects/go/bin:/Users/h4s/.cargo/bin

As a result, things are not being executed as expected.

I can summarize all this as:

purcell commented 1 year ago

Okay, here my suggestion would be to enable exec-path-from-shell-debug before exec-path-from-shell-initialize is called, and then you'll get some details about what's being run and output by your shell.

theherk commented 1 year ago

I think I figured this out. Well... to some extent. I am using Doom and Doom is using this tool, so by me adding this line to the end of my configuration, it seems to be competing with .emacs.d/.local/env. I actually get the correct environment if I remove the explicit call to this function and allow Doom to do its thing. I wish I understood this better, but there is no issue here.

For posterity, the solution was to remove all explicit calls in my configuration to this module, run doom env, and doom sync. The environment is now as expected.

purcell commented 1 year ago

Good to know, thanks for posting about what you learned so that others can potentially benefit too.

montchr commented 10 months ago

It seems to me that the solution mentioned above only works for people using Doom Emacs. However, I still encountered the same issue on macOS (aarch64-darwin) with a vanilla Emacs configuration. Doom has its own way of handling this problem, but that depends on its CLI which at the time of writing is not available as a standalone tool.

I think the GUI behavior has something to do with the way that macOS apps behave when installed under /Applications and opened via the app launcher e.g. /Applications/Emacs.app. Edit: When installed as a user-specific app under ~/Applications/, this package worked perfectly.

FWIW if it matters, I am installing emacs29-macport via Nix [source], which is based on https://bitbucket.org/mituharu/emacs-mac. I'm not sure how $PATH gets read in that case.

Update: I tried out the approach mentioned in https://github.com/nix-community/home-manager/issues/1341#issuecomment-1764378427 to install emacs29-macport as ~/Applications/HMApps/Emacs.app. Opening it via Alfred worked, and making sure exec-path-from-shell was loaded early fixed my $PATH to the expected value.

purcell commented 10 months ago

Update: I tried out the approach mentioned in nix-community/home-manager#1341 (comment) to install emacs29-macport as ~/Applications/HMApps/Emacs.app. Opening it via Alfred worked, and making sure exec-path-from-shell was loaded early fixed my $PATH to the expected value.

Yes, I'm also doing basically the same (though symlinking the apps on the nix-darwin side, not via home-manager) on the same platform with the plain emacs29 and everything works fine for me.