Env vars are ignored when using GUI in macOS #10906
Comments
|
Other interesting thing to notice is that Homebrew added |
|
I just updated to the latest develop version ( What was happening is that I loaded a file that used |
|
Something prevents Could be Emacs 25 as well ? I'm on Emacs 26. |
|
Good point, I'll update to Emacs 26. |
|
Same issue with Emacs 26 :( |
|
I have the same issue. |
|
For me, env vars in |
|
It's not getting vars from |
Andre0991
changed the title
|
are you exporting your variables? env doesn't pick up the changes unless you export them.
if you do this in a shell: env | grep test # prints nothing
TEST="test"
echo $TEST # prints test
env | grep test # prints nothing.
export TEST
env | grep test # prints TEST=testI just did a test and emacs opens up the shell as an interactive shell on mine(zsh though) but one common strategy for dotfiles is to have the non-interactive shell config set the path and then have the interactive one source the non-interactive one. I am not sure which type bash is calling. you can test it by doing this in your bashrc and bash_profile if [ -z "$PS1" ]; then
export TEST="non interactive"
else
export TEST="interactive"
fiand then testing inside |
|
Yes, I'm exporting them. I just tested the snippet you posted. I put it in my
How can I debug that? |
|
where did you put that snippet? i would put it inside whatever the opposite file is and that is where you need to source the other file. |
|
What do you mean by opposite file? |
|
A quick solution for Zsh users. Create/open your Following a better practice, I tend to put env-vars / initializers in ´~/.zshenv´ and the ones suited for an interactive shells in |
the interactive vs non-interactive file. i think it's .bashrc |
|
@fiveNinePlusR I used @aaronjensen, are you using To sum it up, the problem seems to be starting Emacs from GUI. It doesn't pick even |
Yes, with |
|
@aaronjensen, are you starting Emacs from terminal? |
|
@Andre0991 no |
|
I started getting this issue also today after updating. I was using Emacs Plus version, but also have the Emacs Mac versions installed. I usually use Emacs Plus because I like the sexier title bar. However, out of curiosity I tried Emacs Mac and I don't get the problem. Summary: Problem occurs in Emacs Plus started from GUI, but not from command line. Emacs Mac seems to work regardless. |
|
I'm seeing this now with the Emacs Mac version from https://emacsformacosx.com It may be intermittent. I can't get it to work now, but was pretty sure it did a couple of times. Someone mentioned "asynchronously" earlier - is it possible it is a timing issue and things are initializing before it completes? |
|
as a lame workaround I'm doing this for now:
|
|
I added |
|
@mkleehammer Thanks for sharing! Unfortunately, it didn't work for me since some of my layers rely on external utilities (e.g. So my workaround is |
|
@anton-trunov can you test with a quick patch of the spacemacs code there ? Replace the the idea is to pass |
|
@anton-trunov you can try by just evaluating the code above, no need to patch the code I believe. What does the |
|
@syl20bnr Thanks a bunch for looking into this issue! It's much appreciated. I'm working on a layer for the Lean theorem prover and looking forward to be able to contribute back to the Spacemacs community. Here is the output for Alas, applying the patch it didn't work. Here is the log in `Messages: The $ which opam
/usr/local/bin/opam
$ which ocamlmerlin
/Users/anton/.opam/coq.8.8.0/bin/ocamlmerlinJust in case, here is the diff for your patch that I applied: |
|
Oops, missclick. Explanation: on my system (macOS, no change whatsoever in config, vanilla macOS) |
|
@syl20bnr Fair enough — if your install is indeed vanilla, it should certainly be supported. I'm aware of this Usually, they put code in |
|
Hopefully this should remain clean as we remove duplicates from the file so it is not an issue if we source the same file multiple times.
… Le 5 juill. 2018 à 12:11, Paolo G. Giarrusso ***@***.***> a écrit :
@syl20bnr Fair enough — if your install is indeed vanilla, it should certainly be supported. I'm aware of this bash annoyance, but I thought all modern systems work around it — apparently vanilla Mac doesn't do this enough.
Usually, they put code in ~/.profile or ~/.bash_profile to source ~/.bashrc to workaround that bash misbehavior — and /etc/profile sources /etc/bashrc (at least that's still true on my Mac and should be vanilla).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@syl20bnr I appreciate the hard work on this. I could use some clarification on how it is expected to work: It now generates two PATH entries in the env file. I wasn't sure if that is what you were referring to in your previous comment:
Both PATH entries are added to the exec-path so I assume this was by design. I'm asking because I notice it generates a bunch of duplicate entries in exec-path. These are harmless but I wasn't sure if that was expected. Thanks again for working on all of this. |
|
@syl20bnr I hadn't noticed at first, but based on @mkleehammer and @roryk's comments (on 7c9f612), it seems that if you get different definitions for the same variable, behavior gets tricky. Arguably, Spacemacs should ask users to fix the result if there's any duplicate, or any line that doesn't look like IIUC, the user is supposed to remove such duplicate-but-not-really entries by hand — the point of the approach is that Spacemacs can't generate this file robustly, so it just does a best effort and you're supposed to clean up the result by hand. Details below@mkleehammer Not sure such dups are harmless in general, as @roryk noticed on 7c9f612. Usually, if there are conflicting definitions, one overrides the other; since doesn't really mean that the second entry replaces the first (as for all other vars), but some unspecified mixture. So does Worse, it's not clear which entry takes precedence, it depends on the alphabetic order. So, you could get PATH=/usr/bin:/bin
PATH=/usr/local/bin:/usr/bin:/binor PATH=/opt:/usr/bin:/bin
PATH=/usr/bin:/binand depending on how entries are added, it seems For extra fun, that means that emacs would struggle running itself through |
Since bash will source different files depending on its mode, for instance login vs. non-login shells, we fetch the env vars from both a login shell and an interactive non-login shell. We try to cleanup the resulting file by removing duplicates, sorting env vars etc...
|
Please read the comments in the generated env file. It explains all your questions :-)
If there are duplicated entries in `exec-path` though it is not expected and this is a bug. Maybe you mean on Windows with escapes backslashes ?
… Le 5 juill. 2018 à 14:38, Paolo G. Giarrusso ***@***.***> a écrit :
@syl20bnr I hadn't noticed at first, but based on @mkleehammer and @roryk's comments (on 7c9f612), it seems that if you get different definitions for the same variable, behavior gets tricky. Arguably, Spacemacs should ask users to fix the result if there's any duplicate, or any line that doesn't look like KEY=value (say, fortune entries as in 7c9f612, errors because there's no terminal, etc.)?
IIUC, the user is supposed to remove such duplicate-but-not-really entries by hand — the point of the approach is that Spacemacs can't generate this file robustly, so it just does a best effort and you're supposed to clean up the result by hand.
Details below
@mkleehammer Not sure such dups are harmless in general, as @roryk noticed on 7c9f612. Usually, if there are conflicting definitions, one overrides the other; since PATH and exec-path are special, having
PATH=a
PATH=b
doesn't really mean that the second entry replaces the first (as for all other vars), but some unspecified mixture.
So does PATH in the loaded environment match exec-path? From the code I'm not sure (I looked at https://github.com/syl20bnr/spacemacs/blob/7c9f612c4f4a1eda7c8a11194ff2bce21ca53ca0/core/libs/load-env-vars.el and 7c9f612), and Emacs docs suggest this configuration is not well supported.
Worse, it's not clear which entry takes precedence, it depends on the alphabetic order. So, you could get
PATH=/usr/bin:/bin
PATH=/usr/local/bin:/usr/bin:/bin
or
PATH=/opt:/usr/bin:/bin
PATH=/usr/bin:/bin
and depending on how entries are added, it seems /usr/local/bin might be added after /usr/bin, so priority would change. Many put programs in /usr/local/bin to shadow those in /usr/bin, but such program shadowing would fail with PATH=/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin.
For extra fun, that means that emacs would struggle running itself through emacsclient for users installing a non-system emacs in /usr/local, as recommended for OS X — this would risk picking the system's emacsclient. Why would emacs call emacsclient? Well, it could call some program (say, git commit) that calls emacsclient — possibly, the wrong emacsclient, which IME won't connect to the new Emacs.
Did I mention all this is really subtle? Good luck with the effort!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@syl20bnr Double-checked it now, it does document the behavior, I'd still prefer a more robust variant where Spacemacs complains till the file has nothing odd going on, rather than trying to do something good with it. But maybe users prefer trying to make sense of whatever's there, even though it's unreliable, so we'll see what they do. |
|
This is a good idea, we can certainly add a persistent warning at startup when duplicates are found (except PATH). |
|
Tldr: as mentioned, merging PATH can give a wrong one, so you want a warning there too. What’s more, I expect one of the two is the correct one, and the other adds no info, so you only want the user pick the right one. When you start a terminal, you got the right PATH there, but the terminal launched either a login or a non-login shell (but always an interactive one).* Hence, if the PATHs are different one is wrong, and merging them can give a wrong PATH. This reasoning is not completely foolproof, but seems robust enough for a default warning till you fix your environment. EDIT: @Radious reports systems consistent with my predictions at 7c9f612#commitcomment-29623471. |
|
Is anyone getting weird results when sourcing files that define functions? Example: In In Parts of this function is present in my Let me know if my description not enough for reproducing this. My setup is a bit more complicated than that. |
|
Hello, this thread has been extremely useful in debugging my issues with exec-path. While doing so, I have noticed a behavior goes along with the subtleties that @Blaisorblade and @mkleehammer have been talking about: I believe that at some point my exec-path was set such that paths like '/usr/bin' were the first elements. This caused my changes in my Thanks, all, for your help. I'm sorry I can't offer more insight as to how my 'exec-path' got to messed up, but I will post it if I figure it out. |
|
@Roanmh Uh, what you did sounds like the correct fix and something Spacemacs should do by default! Thanks for the report! It's extremely unlikely that clearing Analysis: When Emacs starts it gets some PATH (which for you has So yes, that's similar to what I sketched above, but I missed this even though it's probably going to be even simpler to trigger! |
|
I guess this issue can be closed by now? |
Bash needs the `-l` flag, as pointed out in syl20bnr@6220ace#r29480946 and syl20bnr#10906 (comment).
|
This seems like the most related issue for some additional info. When attempting to use A list of "howevers":
scss-lint (disabled)
- may enable: Automatically disabled!
- executable: Not found
- configuration file: Found at "/Users/edbury/.scss-lint.yml"
scss-stylelint
- may enable: yes
- executable: Found at /Users/edbury/.nvm/versions/node/v8.11.1/bin/stylelint
- configuration file: Found at "/Users/edbury/some/path/.stylelintrc.json"
sass/scss-sass-lint
- may enable: Automatically disabled!
- executable: Not found
- configuration file: Not found
scss
- may enable: Automatically disabled!
- executable: Not found
Flycheck Mode is enabled. Use SPC u C-c ! x to enable disabled checkers.
--------------------
Flycheck version: 32snapshot (package: 20190213.1525)
Emacs version: 26.1
System: x86_64-apple-darwin17.5.0
Window system: ns
|
|
I got exactly the same issue as @edburyenegren-okta mentioned above, but my case if for tslint and I am running Linux with latest trunk Emacs and latest trunk Spacemacs. The error message is
The flycheck-verify-setup result is
|
|
I figured about why, there are two PATH entries in my .spacemacs.env, the commented out the first one and it works. Same solution in this ticket: #12396 (comment) |
|
I spent a bunch of time trying to figure this out until I realized that spacemacs had created a ~/.spacemacs.env which was missing most of my env vars. I ran 'env' in my terminal which had everything setup properly, and replaced my .spacemacs.env with it. Then everything worked. I didn't know about .spacemacs.env... It is documented here: https://develop.spacemacs.org/doc/DOCUMENTATION.html#default-behavior |
|
@bigfish thanks for that, what solved for me was removing .spacemacs.env altogher, and letting spacemacs recreate it. I received this warning upon starting it:
I suspect that the first time I started spacemacs I still hadn't moved from bash, then it copied in the wrong envs. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid! |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid! |
When using GUI Emacs in macOS,
(shell-command-to-string "env")displays my env vars defined in, but not the ones in.bashrc.bash_profile.My config is here.
System Info 💻
Also, I use
bashfrom Homebrew. My default shell is/usr/local/bin/bash(correct according toenv).Related to #10897.
The text was updated successfully, but these errors were encountered: