My Emacs didn't have the same shell environment variable as my terminal.

[https://blog.genenakagaki.com/en/shell-environment-variables-missing-in-emacs.html](https://blog.genenakagaki.com/en/shell-environment-variables-missing-in-emacs.html) Just as the title says. This package saved me a lot of time so I thought I should share it. [https://github.com/purcell/exec-path-from-shell](https://github.com/purcell/exec-path-from-shell) ​ Maybe this is just a macOS issue?

> Maybe this is just a macOS issue? No, it's just a "you didn't start Emacs from your shell environment" issue. Processes *inherit* their environments, after all.

I tried it out, and it worked! Thank for letting me know. I still don't understand much of this part of the system. There's so much stuff to learn

This package makes eMacs startup slow for me for some reason

The best kind of answer: technically correct, but not actually helpful. I guess your suggestion to launch a terminal, then run Emacs from that? I suspect most won't find that a satisfying solution. In practice, well-behaved Unixen allow users to use the same shell configuration for both terminal and GUI sessions; macOS does not. That's the crux of the issue, which is why this is a frequent complaint from Mac users, who think Emacs is doing something wrong, when it's macOS which is the behavioral outlier.

> I guess your suggestion to launch a terminal, then run Emacs from that? I suspect most won't find that a satisfying solution. That is certainly a good way to test, but there's no *need* to involve a terminal; just a shell process. > In practice, well-behaved Unixen allow users to use the same shell configuration for both terminal and GUI sessions If that's happening, it (presumably) means things were executed from a shell process which had read your shell config. I'd be slightly surprised if it was considered "well-behaved" for desktop environments to have to run themselves via a shell, as if you want certain environment vars to be present in your desktop session, there are invariably ways to arrange that. At minimum, what you're describing is not the *nix behaviour I'm familiar with. (Maybe it's a Unity/Gnome/KDE thing though?)

> I guess your suggestion to launch a terminal, then run Emacs from that? I suspect most won't find that a satisfying solution. > > That is certainly a good way to test, but there's no need to involve a terminal; just a shell process. > Sure, okay. But the normal way you get a shell on macOS is to run a terminal emulator, since there isn't a text console. > In practice, well-behaved Unixen allow users to use the same shell configuration for both terminal and GUI sessions > > If that's happening, it (presumably) means things were executed from a shell process which had read your shell config. I'd be slightly surprised if it was considered "well-behaved" for desktop environments to have to run themselves via a shell, as if you want certain environment vars to be present in your desktop session, there are invariably ways to arrange that. > > At minimum, what you're describing is not the *nix behaviour I'm familiar with. (Maybe it's a Unity/Gnome/KDE thing though?) > I don't know the precise mechanism it uses, perhaps a PAM module does it these days? But this has been the norm for Linux since I started using it around 1995, and has been consistent across every WM/DE/DM I've used over those years.

> But the normal way you get a shell on macOS is to run a terminal emulator, since there isn't a text console. That's only if you want an *interactive* shell, though. Whatever is running `emacs` could instead run a shell and tell the shell to run `emacs`. > This has been the norm for Linux since I started using it around 1995, and has been consistent across every WM/DE/DM I've used over those years. I guess YMMV. I can confirm that *my* window manager does not contain the environment set in my `.bashrc` file (for instance by running `xterm /bin/sh` directly from the WM and examining the environment in that terminal); but I'm happy to concede that yours does.