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/[email protected]/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/[email protected]/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/[email protected]/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.

[d12frosted]

@jcsims you are welcome 😸 enjoy! and sorry about the breakage 🙏

[haroldcarr]

@d12frosted

I reinstalled and everything is fine now. Thanks!

I am not sure which of those two scenarios would work best for my use-case and for others.

I start emacs from a script that searches and ordered list and uses the first emacs it finds.
I do this because I have different versions installed on different computers.

Another thing I do is use the NIX package manager. In that case, I often use nix-shell which sets up a PATH which contains links to software need for a project. Then I start emacs. So I need the PATH that is setup by NIX.

Someday I hope to use home-manager and/or direnv to automate that process, but I'm not there yet.

Thanks for your work!

[d12frosted]

@haroldcarr great to hear that it works for you now as well.

Another thing I do is use the NIX package manager. In that case, I often use nix-shell which sets up a PATH which contains links to software need for a project. Then I start emacs. So I need the PATH that is setup by NIX.

My investigation shows that in this case open ignores PATH from your current interactive shell, meaning that nix-shell flow is broken. I guess your particular flow (e.g. starting emacs from terminal in different environments) actually calls for a way to opt-out from PATH injection. But I would love to check few things before I can come to conclusion.

1. Open terminal
2. nix-shell -p rustc - or whatever
3. echo $PATH to see beautifully crafted value mostly consisting of techno-elvish
4. open -n -a /opt/homebrew/Cellar/emacs-plus@29/29.0.50/Emacs.app - to start Emacs
5. From there M-: (getenv "PATH") <ret> and see that it doesn't match the value from step (3).

Can you please do the same and check if you also get different PATH value on step (5)? I know it's a little bit too late, but would be also nice to know if you get a different value without PATH injection. In order to make the testing quick, you can use http://emacsformacosx.com.

The reason I am asking to test it without PATH injection is because it seems that you use exec-path-from-shell, which potentially overrides your PATH anyways. But I only skimmed through your configurations and also I am a casual nix user, so I might be missing something.

Thanks in advance! I hope you don't mind me bothering you with all these flows and checks.

[haroldcarr]

@d12frosted

> echo $PATH
~/.nix-profile/bin:/nix/var/nix/profiles/default/bin:~/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin

> nix-shell -p hello

[nix-shell:...]$ echo $PATH
/nix/store/70j9rsg3kzp4ip26vil4z826wr1gh1cf-bash-interactive-5.1-p16/bin:/nix/store/jnm93vsz7i25zby30d4z7wwrzqbsakdj-clang-wrapper-11.1.0/bin:/nix/store/d952bldhd1pgp4kw39h9dza0dm6c11pb-clang-11.1.0/bin:/nix/store/z53ganlfhl9y7gc76n1n3gc5yb6c0b10-coreutils-9.0/bin:/nix/store/5b9jn0wcnkbvjhkgmw5bmd4zgg97j6v8-cctools-binutils-darwin-wrapper-949.0.1/bin:/nix/store/fjd0p8rk93db76l7wnk2jxh32x9yadfw-cctools-binutils-darwin-949.0.1/bin:/nix/store/4vy30fwh9ak1z72asx8l48aljaq16fw2-hello-2.12/bin:/nix/store/z53ganlfhl9y7gc76n1n3gc5yb6c0b10-coreutils-9.0/bin:/nix/store/dh3ba4a2hfgb5a6bl94iz5c09fv30pbg-findutils-4.9.0/bin:/nix/store/m33g5rk1dvx0iymmqa9iiksi60zif6rj-diffutils-3.8/bin:/nix/store/ck793jv86d1fd8ml18bmgmfjs95gl8fd-gnused-4.8/bin:/nix/store/m6qry1znmhnn9yj37dfk1pvcacprg209-gnugrep-3.7/bin:/nix/store/6ws19cvg2ygsphni9i33cy9l4zjai9wr-gawk-5.1.1/bin:/nix/store/rdv54a5m4392psvpb4dmjl0bzvm5kagb-gnutar-1.34/bin:/nix/store/5343mhf6ncyq8847j7sha7zcw9hmvd97-gzip-1.12/bin:/nix/store/q9f3b34953180w7anjvbbzj01v3d064n-bzip2-1.0.6.0.2-bin/bin:/nix/store/69bd8a3fwlynng2hszy421k3jb4gy11f-gnumake-4.3/bin:/nix/store/vgjv7263732i5s34g40iwlw0avwp2s6j-bash-5.1-p16/bin:/nix/store/2z65mi5f8sqnl9chs8hpg72x5digv4vh-patch-2.7.6/bin:/nix/store/6vp4spvcnsqzjvx3gjncmlgb0in9w6ad-xz-5.2.5-bin/bin:~/.nix-profile/bin:/nix/var/nix/profiles/default/bin:~/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin

[nix-shell:...]$ open -n -a /usr/local/opt/emacs-plus@29/Emacs.app

# in emacs:

(getenv "PATH")

"~/.local/bin:/opt/X11/bin:/Library/Apple/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"

For completeness, starting this way works:

[nix-shell:...]$ /usr/local/opt/emacs-plus\@29/bin/emacs

(getenv "PATH")

"/nix/store/70j9rsg3kzp4ip26vil4z826wr1gh1cf-bash-interactive-5.1-p16/bin:/nix/store/jnm93vsz7i25zby30d4z7wwrzqbsakdj-clang-wrapper-11.1.0/bin:/nix/store/d952bldhd1pgp4kw39h9dza0dm6c11pb-clang-11.1.0/bin:/nix/store/z53ganlfhl9y7gc76n1n3gc5yb6c0b10-coreutils-9.0/bin:/nix/store/5b9jn0wcnkbvjhkgmw5bmd4zgg97j6v8-cctools-binutils-darwin-wrapper-949.0.1/bin:/nix/store/fjd0p8rk93db76l7wnk2jxh32x9yadfw-cctools-binutils-darwin-949.0.1/bin:/nix/store/4vy30fwh9ak1z72asx8l48aljaq16fw2-hello-2.12/bin:/nix/store/z53ganlfhl9y7gc76n1n3gc5yb6c0b10-coreutils-9.0/bin:/nix/store/dh3ba4a2hfgb5a6bl94iz5c09fv30pbg-findutils-4.9.0/bin:/nix/store/m33g5rk1dvx0iymmqa9iiksi60zif6rj-diffutils-3.8/bin:/nix/store/ck793jv86d1fd8ml18bmgmfjs95gl8fd-gnused-4.8/bin:/nix/store/m6qry1znmhnn9yj37dfk1pvcacprg209-gnugrep-3.7/bin:/nix/store/6ws19cvg2ygsphni9i33cy9l4zjai9wr-gawk-5.1.1/bin:/nix/store/rdv54a5m4392psvpb4dmjl0bzvm5kagb-gnutar-1.34/bin:/nix/store/5343mhf6ncyq8847j7sha7zcw9hmvd97-gzip-1.12/bin:/nix/store/q9f3b34953180w7anjvbbzj01v3d064n-bzip2-1.0.6.0.2-bin/bin:/nix/store/69bd8a3fwlynng2hszy421k3jb4gy11f-gnumake-4.3/bin:/nix/store/vgjv7263732i5s34g40iwlw0avwp2s6j-bash-5.1-p16/bin:/nix/store/2z65mi5f8sqnl9chs8hpg72x5digv4vh-patch-2.7.6/bin:/nix/store/6vp4spvcnsqzjvx3gjncmlgb0in9w6ad-xz-5.2.5-bin/bin:~/.nix-profile/bin:/nix/var/nix/profiles/default/bin:~/.local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin"

[d12frosted]

@haroldcarr can you please try the same thing with http://emacsformacosx.com/?

Regarding using emacs binary - it inherits environment normally as you simply spawn a subprocess from nix-shell, unlike when you use open.

[haroldcarr]

@d12frosted

> echo $PATH
~/.nix-profile/bin:/nix/var/nix/profiles/default/bin:~/.local/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin

> nix-shell -p hello

[nix-shell:~]$ echo $PATH
/nix/store/70j9rsg3kzp4ip26vil4z826wr1gh1cf-bash-interactive-5.1-p16/bin:/nix/store/jnm93vsz7i25zby30d4z7wwrzqbsakdj-clang-wrapper-11.1.0/bin:/nix/store/d952bldhd1pgp4kw39h9dza0dm6c11pb-clang-11.1.0/bin:/nix/store/z53ganlfhl9y7gc76n1n3gc5yb6c0b10-coreutils-9.0/bin:/nix/store/5b9jn0wcnkbvjhkgmw5bmd4zgg97j6v8-cctools-binutils-darwin-wrapper-949.0.1/bin:/nix/store/fjd0p8rk93db76l7wnk2jxh32x9yadfw-cctools-binutils-darwin-949.0.1/bin:/nix/store/4vy30fwh9ak1z72asx8l48aljaq16fw2-hello-2.12/bin:/nix/store/z53ganlfhl9y7gc76n1n3gc5yb6c0b10-coreutils-9.0/bin:/nix/store/dh3ba4a2hfgb5a6bl94iz5c09fv30pbg-findutils-4.9.0/bin:/nix/store/m33g5rk1dvx0iymmqa9iiksi60zif6rj-diffutils-3.8/bin:/nix/store/ck793jv86d1fd8ml18bmgmfjs95gl8fd-gnused-4.8/bin:/nix/store/m6qry1znmhnn9yj37dfk1pvcacprg209-gnugrep-3.7/bin:/nix/store/6ws19cvg2ygsphni9i33cy9l4zjai9wr-gawk-5.1.1/bin:/nix/store/rdv54a5m4392psvpb4dmjl0bzvm5kagb-gnutar-1.34/bin:/nix/store/5343mhf6ncyq8847j7sha7zcw9hmvd97-gzip-1.12/bin:/nix/store/q9f3b34953180w7anjvbbzj01v3d064n-bzip2-1.0.6.0.2-bin/bin:/nix/store/69bd8a3fwlynng2hszy421k3jb4gy11f-gnumake-4.3/bin:/nix/store/vgjv7263732i5s34g40iwlw0avwp2s6j-bash-5.1-p16/bin:/nix/store/2z65mi5f8sqnl9chs8hpg72x5digv4vh-patch-2.7.6/bin:/nix/store/6vp4spvcnsqzjvx3gjncmlgb0in9w6ad-xz-5.2.5-bin/bin:~/.nix-profile/bin:/nix/var/nix/profiles/default/bin:~/.local/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin

[nix-shell:~]$ open -n -a /Applications/Emacs.app

# in Emacs

(getenv "PATH")

"~/.local/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin:/nix/store/70j9rsg3kzp4ip26vil4z826wr1gh1cf-bash-interactive-5.1-p16/bin:/nix/store/jnm93vsz7i25zby30d4z7wwrzqbsakdj-clang-wrapper-11.1.0/bin:/nix/store/d952bldhd1pgp4kw39h9dza0dm6c11pb-clang-11.1.0/bin:/nix/store/z53ganlfhl9y7gc76n1n3gc5yb6c0b10-coreutils-9.0/bin:/nix/store/5b9jn0wcnkbvjhkgmw5bmd4zgg97j6v8-cctools-binutils-darwin-wrapper-949.0.1/bin:/nix/store/fjd0p8rk93db76l7wnk2jxh32x9yadfw-cctools-binutils-darwin-949.0.1/bin:/nix/store/4vy30fwh9ak1z72asx8l48aljaq16fw2-hello-2.12/bin:/nix/store/dh3ba4a2hfgb5a6bl94iz5c09fv30pbg-findutils-4.9.0/bin:/nix/store/m33g5rk1dvx0iymmqa9iiksi60zif6rj-diffutils-3.8/bin:/nix/store/ck793jv86d1fd8ml18bmgmfjs95gl8fd-gnused-4.8/bin:/nix/store/m6qry1znmhnn9yj37dfk1pvcacprg209-gnugrep-3.7/bin:/nix/store/6ws19cvg2ygsphni9i33cy9l4zjai9wr-gawk-5.1.1/bin:/nix/store/rdv54a5m4392psvpb4dmjl0bzvm5kagb-gnutar-1.34/bin:/nix/store/5343mhf6ncyq8847j7sha7zcw9hmvd97-gzip-1.12/bin:/nix/store/q9f3b34953180w7anjvbbzj01v3d064n-bzip2-1.0.6.0.2-bin/bin:/nix/store/69bd8a3fwlynng2hszy421k3jb4gy11f-gnumake-4.3/bin:/nix/store/vgjv7263732i5s34g40iwlw0avwp2s6j-bash-5.1-p16/bin:/nix/store/2z65mi5f8sqnl9chs8hpg72x5digv4vh-patch-2.7.6/bin:/nix/store/6vp4spvcnsqzjvx3gjncmlgb0in9w6ad-xz-5.2.5-bin/bin:~/.nix-profile/bin:/nix/var/nix/profiles/default/bin:~/.local/bin:/Applications/Emacs.app/Contents/MacOS/bin-x86_64-10_14:/Applications/Emacs.app/Contents/MacOS/libexec-x86_64-10_14"

[haroldcarr]

What emacsformac does would screw up a nix experience.

This has been useful for me. I am going to stop using open.

[d12frosted]

@haroldcarr Thank you for taking your time to test things. I also learned new things :)

Considering all the information we gathered, I think at this point there is no need to have an option to opt out from PATH injection. Just to make things clear (and not to force anyone to read whole thread), here are the main reasons to keep things as is:

1. Users that don't mess with PATH value gain advantage from PATH injection (especially when it comes to native compilation feature). If for some reason this value is not correct they can either reinstall emacs-plus or update from init.el (one of the options is to use exec-path-from-shell.
2. Users with non-trivial PATH setup should not use Emacs.app regardless of PATH injection. Without it, PATH is not correct, because of complex environment inheritance that includes merging with login environment. With PATH injection, PATH is not correct, because inheritance doesn't happen at all. So the suggestion here is to use emacs binary directly as it spawns a sub-process that properly inherits environment from your shell. I have kind of mentioned this in e9dc471.

That being said, I am not opposed to idea of having ability to opt out from PATH injection, it's just that at this point I see no value (and I want to avoid unnecessary branching in formula). If someone reports use case where is this needed, I will reconsider my decision.

[haroldcarr]

I agree : Emacs.app if PATH is not an issue, otherwise use emacs binary.

Thank you!

[Zeta611]

When I directly run emacs-plus, I get a correct PATH, but when I run it as a service, e.g.,

brew services start d12frosted/emacs-plus/emacs-plus@28

emacsclient -c does not load with a correct PATH.

How do I resolve this issue?

---

I managed to workaround this issue by running emacs daemon emacs --daemon &

[codevbus]

Another issue I seem to be running into is this PATH injection will create problems with a stale path for developers that use any kind version manager for their language interpreters.

NVM comes to mind: it calls nvm.sh when your shell profile is loaded.

This has several functions but one of them is aliasing npm to a default version for the shell by injecting into PATH. If emacs-plus gets installed/compiled with one version being set, and then you change your default version, you have a stale PATH entry and inconsistent behavior when the interpreter is needed.

[d12frosted]

@codevbus I wonder, how do you deal with nvm without PATH injection? To my understanding there are two options.

1. You don't modify PATH inside Emacs. In this case your PATH is the 'default' one, meaning that it's likely that you don't have any npm available (only by absolute path).
2. You do modify PATH inside Emacs (for example, using exec-path-from-shell). In that case you don't care about PATH injection as you will always get the 'correct' value. At least until you change default version without restarting Emacs/copying PATH value again.

I general, due the the way nvm works (at least according to your description), it's a source of troubles for any macOS application, unless it reads profile to setup PATH and updates it time to time. That's why I am curious, how people approach this problem.

[laduke]

Hey sorry to bump this old thread, but it's linked in the readme.
I'm trying nix-darwin, but use homebrew (via nix-darwin) for gui apps.
If I use Emacs.app, then it mostly works, but doom reload for example is like "waaah i can't find the path to emacs"
I'm sure someone knows what to do ?
(if i use just emacs from a terminal, it works fine as far as i can tell)
I'm just trying to avoid having that extra terminal window floating around while emacs is open.
What a mess. Thanks for figuring out so much dumb stuff for us, d12.

[jotaemei]

Hi. I cannot determine why the path is not being injected. From Finder or Spotlight, if I click on or open Emacs.app, the path will not be injected, but if I click on Emacs.app/Contents/MacOS/Emacs, the path will be inserted. It seems like the app is not reading the Info.plist. Has anyone see this?

Edit: I'm on a beta of macOS 15.0. I'm thinking their could be a deprecation issue. TBH, I do not recall this problem before I upgraded.

[d12frosted]

@jotaemei there is an issue for this #720

[jotaemei]

I see. Thank you. I’ll follow the conversation there.

…

On Thu, Sep 12, 2024 at 06:41 Boris Buliga ***@***.***> wrote: @jotaemei <https://github.com/jotaemei> there is an issue for this #720 <#720> — Reply to this email directly, view it on GitHub <#469 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5GEROCVXAG2ELOV3VQ2Z3ZWFVW3AVCNFSM6AAAAABOB6S7KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBVHEYTGNZUHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>