additional stuff added to PATH after starting emacs

[haroldcarr]

I have been using emacs-plus since 27.?.

I install via

brew install emacs-plus --with-ctags --with-imagemagick --with-native-comp

I just upgraded from Big Sur to Monterey then did:

brew update
brew upgrade
brew uninstall emacs-plus@28
brew install   emacs-plus --with-ctags --with-imagemagick --with-native-comp

Now I am getting a behavior that was not happening before.

from a terminal:

echo $PATH
~/.local/bin:~/bin-hosted:/usr/local/texlive/2013/bin/x86_64-darwin:/usr/local/texlive/2020/bin/x86_64-darwin/:~/.sync/.esync/bin:/usr/local/bin:~/.sync/.esync/dotfiles/.unison:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin:/Library/Apple/usr/bin

Then after starting emacs and running a shell in emacs I see:

echo $PATH
/usr/local/opt/gnu-sed/libexec/gnubin:/usr/local/opt/zlib/bin:/usr/local/opt/gnu-getopt/bin:/usr/local/opt/icu4c/bin:/usr/local/opt/sqlite/bin:/usr/local/opt/openssl@1.1/bin:/usr/local/opt/readline/bin:/usr/local/opt/m4/bin:/usr/local/opt/libffi/bin:/usr/local/opt/texinfo/bin:/usr/local/Homebrew/Library/Homebrew/shims/shared:~/.local/bin:~/bin-hosted:/usr/local/texlive/2013/bin/x86_64-darwin:/usr/local/texlive/2020/bin/x86_64-darwin/:~/.sync/.esync/bin:/usr/local/bin:~/.sync/.esync/dotfiles/.unison:/Library/TeX/texbin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin

Note the additional paths put in front of the existing path:

/usr/local/opt/gnu-sed/libexec/gnubin:/usr/local/opt/zlib/bin:/usr/local/opt/gnu-getopt/bin:/usr/local/opt/icu4c/bin:/usr/local/opt/sqlite/bin:/usr/local/opt/openssl@1.1/bin:/usr/local/opt/readline/bin:/usr/local/opt/m4/bin:/usr/local/opt/libffi/bin:/usr/local/opt/texinfo/bin:/usr/local/Homebrew/Library/Homebrew/shims/shared:

Any idea what is going on?

[d12frosted]

Hey,

PATH modification is intentional. See description in README. It all started with various PATH related 'issues' that people reported. And native-comp being also 'affected'. You can read a little bit about it here as well.

That being said, everything before and including /usr/local/Homebrew/Library/Homebrew/shims/shared: should be removed. AFAIK, /usr/local/Homebrew is a pre-M1 HOMEBREW_PREFIX and I don't have access to such machine right now to do proper testing. On my M1 it's removed. See screenshot from my Emacs.app/Info.plist relevant section.

At this point I think of the following action item. Since this PATH injection is not obvious, build script should explicitly mention this. It should also print exact value that will be injected. And possibly, explain how to revert this. In addition, it should print some debug information when run with --verbose flag. And you will be able to share that for us to debug.

WDYT?

[d12frosted]

So I did few changes in #470. You can see example of the output here.

First of all, there is an explicit message saying that your PATH is being injected into Info.plist. And it also prints what is being injected:

==> Injecting PATH value to Emacs.app/Contents/Info.plist
Patching plist at /usr/local/Cellar/emacs-plus@28/28.1/Emacs.app/Contents/Info.plist with following PATH value:
/usr/local/lib/ruby/gems/2.7.0/bin
/usr/local/opt/ruby@2.7/bin
/usr/local/opt/pipx_bin
/Users/runner/.cargo/bin
/usr/local/opt/curl/bin
/usr/local/bin
/usr/local/sbin
/Users/runner/bin
/Users/runner/.yarn/bin
/Users/runner/Library/Android/sdk/tools
/Users/runner/Library/Android/sdk/platform-tools
/Users/runner/Library/Android/sdk/ndk-bundle
/Library/Frameworks/Mono.framework/Versions/Current/Commands
/Users/runner/.dotnet/tools
/Users/runner/.ghcup/bin
/Users/runner/hostedtoolcache/stack/2.7.5/x64
/usr/bin
/bin
/usr/sbin
/sbin

This is the value of PATH in the runner. For you it should be different, of course. Also notice, that there is no shims/shared entry.

Secondly, there is a message about PATH injection in caveats section:

==> Caveats
Emacs.app was installed to:
  /usr/local/opt/emacs-plus@28

To link the application to default Homebrew App location:
  ln -s /usr/local/opt/emacs-plus@28/Emacs.app /Applications

Your PATH value was injected into Emacs.app/Contents/Info.plist

Report any issues to http://github.com/d12frosted/homebrew-emacs-plus

Last, but no the least, I changed how brew specific PATH entries are being removed, and I possibly fixed your issue. Though not sure 🤷 Would be nice if you could test it.

In case you want to test it before I merge the PR, just do the following (assuming you have jq installed).

1. cd $(brew tap-info --json d12frosted/emacs-plus | jq -r '.[0].path') && git switch feature/verbose-path-injection
2. brew install emacs-plus@28 [OPTIONS]

Thanks.

[d12frosted]

Oh, and by the way, if you find this feature troubling, please share your thoughts on this. If PATH injections gets some critical cons, I might make it possible to opt out. Though in general I think it's a good feature all things considered.

[d12frosted]

FYI, PR is merged. So you can try again building from master. If you still get junk in PATH, please let me know and share output.

[jcsims]

I think I ended up with unexpected formatting in my PATH, after a recent reinstall of emacs-plus. This is the relevant section from Info.plist (notice the square brackets and comma-delimited paths):

<dict>
  <key>PATH</key>
  <string>[/Users/jcsims/.nix-profile/bin, /nix/var/nix/profiles/default/bin, /usr/local/bin, /Users/jcsims/bin, /Users/jcsims/go/bin, /Users/jcsims/.cargo/bin, /opt/homebrew/bin, /opt/homebrew/sbin, /usr/bin, /bin, /usr/sbin, /sbin]</string>
</dict>

This resulted in e.g. /usr/bin not being on the PATH for Emacs startup, so ran into issues finding /usr/bin/as for native compilation on startup. I instead ran from the terminal to get around this for now.

[haroldcarr]

@jcsims I just reinstalled. I have the same problem.

In a shell before starting emacs (edited for brevity):

echo $PATH
~/.local/bin:~/bin-hosted:~/.sync/.esync/bin:/usr/local/bin:...

After starting emacs, in a shell inside emacs (edited):

echo $PATH
[~/.local/bin, ~/bin-hosted, ~/.sync/.esync/bin, /usr/local/bin, ...]

[haroldcarr]

Regarding path injection : I suggest making an option, default OFF.

[d12frosted]

@jcsims @haroldcarr oops, that's by mistake. Fixed that in 3737ab5 One of the reasons for PATH injection is to make native compilation to work even when you run Emacs.app from finder/docker and this formatting just broke everything. Apologies 🙏

@haroldcarr It's nice to see that the original issue is fixed as well, e.g. no junk is appended. Still not sure why you got it, maybe brew prefix is messed up 🤷

@haroldcarr why do you think it should be off? Genuinely would like to hear why you specifically want to disable it and why you think it should be disabled by default. Just don't want to break some workflows in pursuit of helping others. Well, of course, aside this bug that should be fixed and forgotten.

[haroldcarr]

I now understand that you need this to make native compilation work when starting Emacs.app from finder/docker. So having it on my default seems like a good idea. But it might be good to have an option to disable it.

I start emacs from a script (run from a terminal that has $PATH set to what is needed) that essentially does:

EMACS281=/usr/local/Cellar/emacs-plus@28/28.1/Emacs.app

open -n -a ${EMACS281} --args "$@"

The script actually decides which version of emacs is available on the particular machine I am starting it on and start that version.

[jcsims]

@jcsims @haroldcarr oops, that's by mistake. Fixed that in 3737ab5 One of the reasons for PATH injection is to make native compilation to work even when you run Emacs.app from finder/docker and this formatting just broke everything. Apologies 🙏

@haroldcarr It's nice to see that the original issue is fixed as well, e.g. no junk is appended. Still not sure why you got it, maybe brew prefix is messed up 🤷

@haroldcarr why do you think it should be off? Genuinely would like to hear why you specifically want to disable it and why you think it should be disabled by default. Just don't want to break some workflows in pursuit of helping others. Well, of course, aside this bug that should be fixed and forgotten.

@d12frosted yay, thanks for the quick fix! I reinstalled and the PATH key in Info.plist is in the right format.

[d12frosted]

@haroldcarr I see, thanks for sharing your use case. Since you run this script from terminal that has some PATH set I started to wonder how PATH injection affects environment inside Emacs. There are two questions I asked myself. Does open inherits environment in the spawned application. And which one? Without going too much into details (if you wish, I can share them, just don't want to scare anyone with wall of text and test cases), I've come to the following conclusions.

1. If Emacs.app doesn't have PATH injected in Info.plist, then open inherits value of PATH variables from login shell AND current shell environment. E.g. if you modify PATH in your script, then you get those values in Emacs.app out of box. Though you can't get rid of the PATH entry that is part of login shell. E.g. if your login shell PATH has dir1 as part of tis value, then even if you change value of PATH in your script to a value that doesn't contain dir1, it will still be present in Emacs.app.
2. If Emacs.app has PATH injected in Info.plist, then this value is set according to Info,plist and nothing gets inherited. E.g. if you modify PATH in your script, this modification is ignored.

The first one sounds nice. First of all, I didn't expect inheritance to work. And secondly, I didn't expect it to work in this way.

The second one sounds meh from the first point of view. But in case it is set to correct value, you don't need to mess with it and it brings lots of value. And in case you need to mess around with it, you can always do it from init.el.

So hopefully this makes everyone happy without adding more branching to the formula.

Anyways, let me know if you want me to share all details I gathered during this small investigation. And thank you for reporting this issue. Not only I have improved PATH injection procedure, I've also learned few new things. The only sad part is that accidentally I've broken Emacs for some users in-between.