[General]: exec-paths not being set in Sequoia for emacs-plus@30

[efroemling]

Issue description

I just updated my setup to beta 7 of macOS Sequoia and noticed that the path values embedded in the Emacs.app's plist no longer seem to be getting applied. I did a fresh uninstall/reinstall of emacs-plus@30 to no avail. It seems the values get inserted into the plist correctly but emacs doesn't seem to be applying them.

For now I'm just manually setting exec-path to what the plist contains in my .emacs so I'm all good, but wanted to mention this just to get it on the radar since Sequoia RC is likely a week or two out. Anyone else running the beta and seeing this same behavior?

[efroemling]

Hmm; just tested with -q and the embedded paths are showing up, so it seems it might be a weird interaction with something in my .emacs and Sequoia. I'll poke around and will follow up or close this soon.

FOLLOWUP: Oops that was just because I ran emacs -q from a terminal so it picked up my paths that way. If I temporarily blow away my .emacs and launch Emacs.app via the finder I do not see the embedded paths.

[d12frosted]

Can you double check that PATH value under less $(brew --cellar emacs-plus@30)/30.0.50/Emacs.app/Contents/Info.plist (adjust it to relevant version of Emacs.app you are starting) is a correct one?

If it is, I have no clues why on Sequioia it doesn't work and I am not going to upgrade on my laptops as I need them stable - can't afford something to break :) But I will try to get my hands on another machine to test.

[jotaemei]

Hi all. I had made the mistake of downgrading to emacs-plus@29 to resolve this before realizing that it was likely the upgrade to a beta of the upcoming macOS version.

One curious thing I've noticed is that while clicking on the .app bundle does not set the path, if you click on the executable within the bundle (Emacs.app/Contents/MacOS/Emacs), the path from Info.plist will be set. Likewise, the path will be set correctly if you click on the Bash script at /usr/local/Cellar/emacs-plus@##/##.#/bin/emacs that calls (exec) the executable.

[efroemling]

Can you double check that PATH value under less $(brew --cellar emacs-plus@30)/30.0.50/Emacs.app/Contents/Info.plist (adjust it to relevant version of Emacs.app you are starting) is a correct one?

If it is, I have no clues why on Sequioia it doesn't work and I am not going to upgrade on my laptops as I need them stable - can't afford something to break :) But I will try to get my hands on another machine to test.

Sorry for the slow reply here, but just checked and can confirm that the PATH in the plist seems to be correct; it's just somehow not ending up applied. Also just confirmed this is still happening on the release version of Sequoia in case you're planning on upgrading at this point and can try to repro.

[jotaemei]

Also just confirmed this is still happening on the release version of Sequoia in case you're planning on upgrading at this point and can try to repro.

That's a shame. I was hoping (though imagining it would be unlikely) that it would be resolved in the finalized Sequoia release. I've not been able to upgrade from the beta though. as AFAICT, the beta is being classified by the OS itself as the release. Either that, or my upgrade from the beta to the release took all of 1-2 mins when I restarted the computer last night.

[d12frosted]

I will try to upgrade one of my machines to Sequoia ASAP (still need to plan to do it without any potential work disruptions), but meanwhile you can use https://github.com/purcell/exec-path-from-shell

[d12frosted]

Ok, so I've upgraded one of my laptops and I can confirm the difference in behaviour between Sequoia and previous OS version.

Test 1

mv ~/.config/emacs ~/.config/emacs.bak
export PATH=/opt/homebrew/opt/llvm/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
brew install emacs-plus@30

Result: plist contains all the correct values, but when I start Emacs.app from Finder the PATH value (I inspect it using M-! echo $PATH <ret>) matches the one I have in Terminal session.

Test 2

Emacs 29.4-1 from Emacs For macOS.

Result: the PATH value matches the one I have in Terminal session.

---

I don't fully understand what's happening and what has changed. But it seems that there is something happening even in Sonoma. Maybe I am just tired and made a mistake in my tests 🤷

[cfclrk]

On Emacs 29: I just upgraded to Sequoia and I am getting this problem as well. I can see my intended $PATH value in Info.plist. But when Emacs starts, PATH is not customized:

(getenv "PATH")
"/usr/bin:/bin:/usr/sbin:/sbin"

If I run M-! echo $PATH, Emacs shows me the full, expected PATH. Which is weird.

Using exec-path-from-shell is working for me in the interim until we figure this problem out.

[aaronjensen]

@d12frosted Emacs for macOS appears to use a Rust launcher that gets and sets the environment variables:

https://github.com/caldwell/build-emacs/blob/master/launch.rs#L101
https://github.com/caldwell/build-emacs/blob/master/launch.rs#L172-L196

In other words, it appears to have exec-path-for-shell built-in. This is convenient, but likely increases startup time in the same way that exec-path-for-shell does. Would need to test, and it'd be dependent on a person's shell initialization scripts.

[milanglacier]

The strangest thing to me is that, emacs-plus even doesn't respect ~/.zprofile now.

PATH shows /usr/bin:/bin:/usr/sbin:/sbin which is not even the same as from ~/.zprofile.

Theoretically, even the path injection does not work, then the app should still read from the login shell configuration file, right?

[aaronjensen]

@milanglacier Not on macOS, at least not to my knowledge. Until the PATH injection, we always had to use exec-path-from-shell.

[milanglacier]

@milanglacier Not on macOS, at least not to my knowledge. Until the PATH injection, we always had to use exec-path-from-shell.

My understanding is that, while macOS apps launched from finder do not read from the interactive shell configuration file (aka ~/.zshrc), they should read login shell configuration file, i.e. ~/.zprofile. This is the case when I use neovide (aka the GUI app for neovim).

And this is not the case for emacs, which is so weird.

[milanglacier]

Ok, I find another way to use the finder to open emacs, by using the automator:

1. open automator app

2. choose application

3. select the action run shell script

4. type the following shell script

   source ~/.zprofile
   source ~/.zshrc
   emacs &

5. type command + s and save it to /applications

6. then you can click the icon and run emacs

we can also change the icon to the emacs icon following what kitty suggested: kitty's tutorial

In this way, I do not need to use the exec-from-shell which significantly reduced my startup speed.

[onetom]

6. then you can click the icon and run emacs

it did run, but only if i specified an absolute path (/usr/local/bin/emacs) to emacs.
the problem however is that automator shows a spinning gear in the menu bar until u quit emacs.

[onetom]

so im still getting this error:

...
==> ./autogen.sh
Last 15 lines from /Users/onetom/Library/Logs/Homebrew/emacs-plus@30/01.autogen.sh:
2024-11-19 06:56:51 +0000

./autogen.sh

Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Running 'autoreconf -fi -I m4' ...
./autogen.sh: /usr/local/opt/autoconf/bin/autoreconf: /usr/bin/perl5.30: bad interpreter: No such file or directory

If reporting this issue please do so at (not Homebrew/brew or Homebrew/homebrew-core):
  https://github.com/d12frosted/homebrew-emacs-plus/issues

These open issues may also help:
[General]: exec-paths not being set in Sequoia for emacs-plus@30 https://github.com/d12frosted/homebrew-emacs-plus/issues/720
brew install emacs-plus@30  20.91s user 8.19s system 65% cpu 44.532 total

after fixing the shebangs, to use /usr/bin/perl5.34 instead, in the following files:

• /usr/local/opt/autoconf/bin/autoreconf
• /usr/local/Cellar/autoconf/2.72/bin/autom4te
• /usr/local/Cellar/autoconf/2.72/bin/autoheader
  the installation (without any custom options) has succeeded.

I suspect this situation might be caused by the use of OpenCore Legacy Patcher, which is not supported, as the brew installer page states.

Starting it however gave some errors:

$ osascript -e 'tell application "Finder" to make alias file to posix file "/usr/local/opt/emacs-plus@30/Emacs.app" at posix file "/Applications" with properties {name:"Emacs.app"}'
alias file Emacs.app of folder Applications of startup disk

$ open -a Emacs
_LSOpenURLsWithCompletionHandler() failed for the application /usr/local/opt/emacs-plus@30/Emacs.app with error -54.

$ open -a /usr/local/opt/emacs-plus@30/Emacs.app 
_LSOpenURLsWithCompletionHandler() failed for the application /usr/local/opt/emacs-plus@30/Emacs.app with error -54.

unless I directly run the binary:

$ /usr/local/opt/emacs-plus@30/Emacs.app/Contents/MacOS/Emacs &