OS X warning from default bashrc

[jacobmoe]

The following warning appears when starting emacs on OS X:

Warning (emacs): You appear to be setting environment variables in your .bashrc or .zshrc: those files are only read by interactive shells, so you should instead set environment variables in startup files like .bash_profile or .zshenv.  See the man page for your shell for more info.  In future, exec-path-from-shell will not read variables set in the wrong files.

I'm using the standard OS X .bash_profile for shell config. This warning results from the default system-wide bashrc found in /private/etc/bashrc. Tested by renaming that file, and no longer saw the warning. Since /private/etc/bashrc is a read-only system default, this warning should probably be suppressed on OS X.

[purcell]

I'd rather figure out why than just suppress it. It must be somehow due to /etc/bashrc_Apple_Terminal. What variables are you loading via exec-path-from-shell?

[purcell]

In fact, I can't reproduce this on my OS X machine (10.11.1).

[jacobmoe]

Ah, this happened after I started using spacemacs. I assumed it was caused by a different version of exec-path-from-shell from my own config, which didn't have a problem. I'm on OS X 10.11.1, emacs 25.0.50.1.

Other than initialization, a search of spacemacs only finds, (exec-path-from-shell-copy-env "GOPATH").

[purcell]

I just pushed a change which will include in the warning message the specific vars that are being set in the wrong startup files. So when that gets built as a fresh package on MELPA and you update it, it would tell us which of the vars is being set.

[jacobmoe]

Grabbed it from master. Here's the new warning: Warning (emacs): You appear to be setting environment variables ("MANPATH") in your .bashrc or .zshrc

Files containing MANPATH:

/Users/jacobmoe/dotfiles/emacs.d/elpa/exec-path-from-shell-20151120.1421/exec-path-from-shell.el
/Users/jacobmoe/dotfiles/emacs.d/elpa/helm-20151120.1153/helm-man.el
/Users/jacobmoe/src/ruby-2.2.3/thread.c
/private/etc/manpaths.d
/private/etc/manpaths
/Users/jacobmoe/src/ruby-2.2.2/thread.c
/Users/jacobmoe/src/ruby-2.1.2/thread.c
/opt/vagrant/embedded/gems/gems/bundler-1.7.11/lib/bundler/runtime.rb
/opt/vagrant/embedded/gems/gems/bundler-1.7.11/lib/bundler.rb

[halbtuerke]

I get this error with the default configuration of oh-my-zsh but unfortunately I have no clue how to debug this problem. Do you have any hint for what I should be looking for?

[jacobmoe]

This appears to be only an issue with the GUI, likely due to

https://github.com/syl20bnr/spacemacs/blob/master/layers/%2Bdistribution/spacemacs-base/packages.el#L447

MANPATH is not set outside of emacs, but in the emacs shell its value is ba691c29705f7e4e976bcae906b69862Saving session...

@halbtuerke Are you using spacemacs in the GUI on OS X?

[halbtuerke]

No, I'm not using spacemacs. But I'm using the GUI version of Emacs on OS X.

[purcell]

MANPATH is not set outside of emacs, but in the emacs shell its value is ba691c29705f7e4e976bcae906b69862Saving session...

Erk, that doesn't look right. Can you add (setq exec-path-from-shell-debug t) to the start of your init.el? This should produce more debug output at startup time.

[halbtuerke]

The debug output on my machine is the following:

Invoking shell /usr/local/bin/zsh with args ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-c72b2dc4cb2495f181bc472bd82b1683}\" \"${MANPATH-c72b2dc4cb2495f181bc472bd82b1683}\"")
Shell printed: "__RESULT/Users/patrick/.gem/ruby/2.2.2/bin:/Users/patrick/.rubies/ruby-2.2.2/lib/ruby/gems/2.2.0/bin:/Users/patrick/.rubies/ruby-2.2.2/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin:/Library/TeX/texbin:/Users/patrick/Library/Python/2.7/bin:/Users/patrick/.local/bin:/usr/local/opt/go/libexec/bin:/Users/patrick/Coding/go/bin:/usr/local/share/npm/bin:/Users/patrick/bin:/Users/patrick/.fzf/bin/usr/share/man:/usr/local/share/man:/opt/X11/share/man:/usr/local/MacGPG2/share/man:/Library/TeX/Distributions/.DefaultTeX/Contents/Man:/Users/patrick/.fzf/man"
Invoking shell /usr/local/bin/zsh with args ("-l" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-30a821240430073d01376e3ae0b0a28b}\" \"${MANPATH-30a821240430073d01376e3ae0b0a28b}\"")
Shell printed: "__RESULT/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin:/Library/TeX/texbin:/Users/patrick/Library/Python/2.7/bin:/Users/patrick/.local/bin:/usr/local/opt/go/libexec/bin:/Users/patrick/Coding/go/bin:/usr/local/share/npm/bin:/Users/patrick/bin:/Users/patrick/.fzf/bin/usr/share/man:/usr/local/share/man:/opt/X11/share/man:/usr/local/MacGPG2/share/man:/Library/TeX/Distributions/.DefaultTeX/Contents/Man:/Users/patrick/.fzf/man"
Invoking shell /usr/local/bin/zsh with args ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s' \"${GOPATH-a3d919562065edd25de72872fb5be932}\"")
Shell printed: "__RESULT/Users/patrick/Coding/go"
Invoking shell /usr/local/bin/zsh with args ("-l" "-c" "/usr/bin/printf '__RESULT\\000%s' \"${GOPATH-f59c749f0e2f91f46a41f5cf65f244ef}\"")
Shell printed: "__RESULT/Users/patrick/Coding/go"

[halbtuerke]

I think I fixed it. I moved the configurations of fzf, nvm and chruby to .zshenv and now I don't get the warning when starting Emacs.

[purcell]

@halbtuerke Great - that was the intention of the warning. :-)

[JP-Ellis]

For people who wish to have different $PATH variable in an interactive shell to the usual shell, how is this warning suppressed?

For example, if I (interactively) navigate to a path which has a python virtualenv set up, the $PATHenvironment automatically gets adjusted to load executables from the virtualenv, but I definitely do not want to have these executables in my global $PATH. Similarly, many Ruby projects have per-project binaries which don't really belong in a global $PATH environment.

[jacobmoe]

@purcell, my debug info:

Invoking shell /bin/bash with args ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-eec8a1d3c6ae8ff157131f6b862d12e8}\" \"${MANPATH-eec8a1d3c6ae8ff157131f6b862d12e8}\"")
Shell printed: "Restored session: Mon Nov 23 09:27:26 EST 2015
__RESULT/Users/jacobmoe/bin:/Users/jacobmoe/.gem/ruby/2.2.3/bin:/Users/jacobmoe/.rubies/ruby-2.2.3/lib/ruby/gems/2.2.0/bin:/Users/jacobmoe/.rubies/ruby-2.2.3/bin:/Applications/Postgres.app/Contents/MacOS/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Users/jacobmoe/bin:/Applications/Postgres.app/Contents/MacOS/bin:/usr/local/sbin:/usr/local/mysql/bin:/Users/jacobmoe/code/go/bin:/usr/local/mysql/bin:/bin:/Users/jacobmoe/code/go/bineec8a1d3c6ae8ff157131f6b862d12e8Saving session...
...saving history...
...completed.
"
Invoking shell /bin/bash with args ("-l" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-3be2f568bb9b41cdcf481f83defa2da3}\" \"${MANPATH-3be2f568bb9b41cdcf481f83defa2da3}\"")
Shell printed: "__RESULT/Users/jacobmoe/bin:/Users/jacobmoe/.gem/ruby/2.2.3/bin:/Users/jacobmoe/.rubies/ruby-2.2.3/lib/ruby/gems/2.2.0/bin:/Users/jacobmoe/.rubies/ruby-2.2.3/bin:/Applications/Postgres.app/Contents/MacOS/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Users/jacobmoe/bin:/Applications/Postgres.app/Contents/MacOS/bin:/usr/local/sbin:/usr/local/mysql/bin:/Users/jacobmoe/code/go/bin:/usr/local/mysql/bin:/bin:/Users/jacobmoe/code/go/bin3be2f568bb9b41cdcf481f83defa2da3"

[jschaf]

I'm not sure this is related but removing the following code fixed it for me.

[ -z "$PS1" ] && return

Glancing at the source, it seems exec-path-from-shell now runs non-interactively. The snippet above will exit the script if the shell is not interactive, so $PATH will look different to a non-interactive process compared to an interactive shell if there's any additional customization past that line.

[purcell]

The big picture here is that I will eventually remove -i from the default shell arguments, because I believe that's the right thing to do, and I want to encourage people to set up their shells properly. I'm trying out this warning in the meantime to find out if there's a problem with that plan. The warning can currently be suppressed by either fixing the shell config or setting exec-path-from-shell-arguments to '("-l").

[JP-Ellis]

I completely understand where you're coming from, and it is really good to encourage people to set up shells properly; however; I do think there are some legitimate cases where the global $PATH variable can differ from the interactive $PATH variable. I also think there are cases where the user doesn't have a choice (for example, if the computer is administered by someone else).

In my experience, I have encountered the following cases:

• Some projects (such as those using Python or Ruby) can have project-specific binaries which should be loaded on the fly and do not belong in the global $PATH.
• At my university, certain programs are only accessible after executing the appropriate shell script which mount specific directories and adjusts the environment variables.
• If the user does not have sudo access, an improper system-wide configuration (perhaps done by one of the system administrator, or installed by some package) will cause this error to appear despite the user having perfectly good scripts. For example, /etc/zshrc could be set up such that it completely overwrites $PATH (this would be terrible I know, but it wouldn't surprise me entirely).

Perhaps you could add some option which replaces the warning with a message.

In the meantime, I have adjusted exec-path-from-shell-arguments and it works all fine now.

[magthe]

I've been bit by this on Linux, with zsh. The output when turning on debug is

Invoking shell /usr/bin/zsh with args ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-a7eb268137995dda67083d70138f6457}\" \"${MANPATH-a7eb268137995dda67083d70138f6457}\"")
Shell printed: "__RESULT^@/home/magnus/bin:/home/magnus/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl^@a7eb268137995dda67083d70138f6457TERM environment variable not set.
"
Invoking shell /usr/bin/zsh with args ("-l" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-efe416d259564be2f6e2e0d7d535e150}\" \"${MANPATH-efe416d259564be2f6e2e0d7d535e150}\"")
Shell printed: "__RESULT^@/home/magnus/bin:/home/magnus/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl^@efe416d259564be2f6e2e0d7d535e150"

If I remove MANPATH from exec-path-from-shell-variables I get the warning on PATH instead. The debug output then becomes

Invoking shell /usr/bin/zsh with args ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s' \"${PATH-c93f10e5f78006bc62e3ba90fd24d74c}\"")
Shell printed: "__RESULT/home/magnus/bin:/home/magnus/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perlTERM environment variable not set.
"
Invoking shell /usr/bin/zsh with args ("-l" "-c" "/usr/bin/printf '__RESULT\\000%s' \"${PATH-6cd7100d2138e5fb980487ed417d9871}\"")
Shell printed: "__RESULT/home/magnus/bin:/home/magnus/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl"

As you can see the environment variables are actually the same in both interactive and non-interactive shells, but the code in exec-path-from-shell fails to recognize this.

[StreakyCobra]

TERM environment variable not set.

@magthe It looks like to be the difference. What if you try to play with this varible? (setting/unsetting) it?

[magthe]

@StreakyCobra Indeed, that is the difference, but where should I set it?

ATM it is set in all my terminals, but I'm not sure where it comes from.

[StreakyCobra]

I'm not sure, but as the warning says about interactive vs non-interactive shells and .zshrc vs .zshenv, try to define in one file or the other or both. I don't know if it will help, just trying ^^

[magthe]

@StreakyCobra I'll try it, but I don't think it really belongs there, TERM is related to the terminal, not to the shell (AFAIU).

[magthe]

I set it to vt100 (seemed as good a value as any) but the issue remains, now the difference has changed though (I had to use cat -A to get the non-printing stuff out properly):

Invoking shell /usr/bin/zsh with args ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-f9446344eae823955844e5d1018fad70}\" \"${MANPATH-f9446344eae823955844e5d1018fad70}\"")$
Shell printed: "__RESULT^@/home/magnus/bin:/home/magnus/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl^@f9446344eae823955844e5d1018fad70^[[H^[[J"$
Invoking shell /usr/bin/zsh with args ("-l" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-260ba1d09795fe011a830b317488342d}\" \"${MANPATH-260ba1d09795fe011a830b317488342d}\"")$
Shell printed: "__RESULT^@/home/magnus/bin:/home/magnus/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl^@260ba1d09795fe011a830b317488342d"$

I wonder where those non-printing characters come from.

[joncol]

Also got this warning on Mac OS 10.11.1, using Fish shell. Setting exec-path-from-shell-arguments to '("-l") removed the warning.

[benmezger]

I am getting the following error after an update:

Warning (emacs): You appear to be setting environment variables ("PATH") in your .bashrc or .zshrc: those files are only read by interactive shells, so you should instead set environment variables in startup files like .bash_profile or .zshenv.  Refer to your shell's man page for more info.  In future, exec-path-from-shell will not read variables set in the wrong files.
Warning (emacs): You appear to be setting environment variables ("GPG_AGENT_INFO") in your .bashrc or .zshrc: those files are only read by interactive shells, so you should instead set environment variables in startup files like .bash_profile or .zshenv.  Refer to your shell's man page for more info.  In future, exec-path-from-shell will not read variables set in the wrong files.

All my PATH's are set in my .zshrc, so I am not sure how to fix this. I am using prezto's zsh's framework, any clue?

[StreakyCobra]

I posted this comment on https://github.com/syl20bnr/spacemacs/issues/3920, the Spacemacs issue following this problem. I cross-post my message here as it can be an useful review of the general problem.

---

It seems .bash_profile/.zshenv is the right place to define $PATH and $MANPATH, for being used both by interactive and non-interactive shells. exec-path-from-shell is trying to make people do this, by comparing both version and throwing a warning in case of difference. It's a good intention, but there are some drawbacks:

• People could be wanting to have different $PATH for valid reasons.
• Even when moving $PATH related stuff to .zshenv, some people still have the warning. I'm myself victim of this, and I don't know what to do more. Some suggest it can be oh-my-zsh related.

You can do what the warning message says and move PATH and MANPATH related definition to you shell environment file (.bash_profile, .zshenv). If the message still appear or if you don't want to do this, as there is no option to disable the warning, the current workarounds to remove it are:

• Use (setq exec-path-from-shell-arguments '("-l")), if you don't care about all this and don't have $PATH problems within emacs.
• @syohex solution if you have $PATH problems within emacs, and don't want this warning.
• @gilbertkennen suggested that this package is only useful for OS X users, so it can maybe be removed for other users. I'm not sure about this though.

[benmezger]

Ok, I have the following in my emacs.el;

;; exec-path-from-shell
(require 'exec-path-from-shell)

(when (memq window-system '(mac ns))
    (exec-path-from-shell-initialize))

(provide 'setup-exec-path-from-shell)

I did a full grep in my dotfiles, and all my PATHS are set at .zshenv, but since I am using prezto's framework, perhaps that's where the problem is coming from. I had to remove (exec-path-from-shell-copy-env "GPG_AGENT_INFO") due the warning. But I need my GPG_AGENT_INFO, any idea how to fix this? GPG_AGENT_INFO is set at prezto's framework.

I like the whole idea, but I will this will break lots of stuff, specially when people are using frameworks.

[rakkesh]

All my PATH's are set in my .zshrc, so I am not sure how to fix this. I am using prezto's zsh's framework, any clue?

@ephexeve I use zsh prezto configuration for work, and I know that it does not promote having environment variables in ~/.zshrc. Please refer to the README.md file in runcoms directory.

Moving on to this issue, I have two mac os x machines with zsh prezto and spacemacs setup almost similarly. On one machine, spacemacs starts without a warning but on the other it reports this issue and that ("PATH" "MANPATH") are being set from ~/.zshrc, which is not correct. I have verified that neither PATH or MANPATH is set by prezto.

$ cd ~/.zprezto
$ grep -E -R '(PATH|MANPATH)\=' ./*

No result.

[benmezger]

@rakkesh then I am not sure why exec_path_from_shell is complaning about, since there isn't any PATH anywhere else except in .zshenv.

[rakkesh]

prezto does set path but in ~/.zprofile. If I add an option to ignore case in the grep command in my comment above, i.e.,

$ grep -i -E -R '(PATH|MANPATH)\=' ./*

I get a result of all init.zsh files from modules subdirectory .

[jacobmoe]

I'm no longer seeing this issue after updating spacemacs.

[stefano-m]

@purcell, I have another edge case you might want to consider.

I am on a Linux machine where bash is the default shell and I cannot change it because I do not have root privileges.

I set up my environment in ~/.bash_profile, but then I fall back to zsh.

The code goes something like

# set env vars etc.
if [[ -x /usr/bin/zsh ]]; then
  export SHELL=/usr/bin/zsh
  exec /usr/bin/zsh -l
else
   # sometimes zsh is not available.
    [[ -f ~/.bashrc ]] && . ~/.bashrc
fi

This works nice and well in the terminal (and when I start Emacs from the terminal), I do not have to duplicate the environment in ~/.zshenv, but when I run Emacs in the X-windows system, exec-path-from-shell picks up zsh as shell and ignores the setup in ~/.bash_profile.

This complicates things for me because I have some applications installed in non-default paths that I set in ~/.bash_profile.

I understand that this is an edge case, but any help is appreciated.

[stefano-m]

I have figured out a (quite ugly) workaround:

at the bottom of ~/.zshenv, add

. ~/.bash_profile

and modify the previous snipped in ~/.bash_profile as follows

if [[ -x /usr/bin/zsh ]]; then
    # Emacs workaround for https://github.com/purcell/exec-path-from-shell/issues/34
    if [[  ! "x$SHELL" == "x/usr/bin/zsh" ]]; then
        export SHELL=/usr/bin/zsh
        exec  /usr/bin/zsh -l
    else
        return
    fi
else
    [[ -f ~/.bashrc ]] && . ~/.bashrc
fi

any idea better than this one?

[purcell]

@stefano-m Or, in your first example, only source .bashrc if the current shell is interactive (and also pass "-i" to zsh in that case).

[ethanluoyc]

I would also like to mention another valid reason for having different PATH. https://github.com/syl20bnr/spacemacs/issues/4195

[purcell]

@ethanluoyc Not the same issue -- I commented directly on the issue you referenced.

[AstonJ]

Sorry to resurrect this Steve, but I am getting a similar issue.

I have installed the package and added the following lines to my init.el file:

(package-initialize)
(when (memq window-system '(mac ns))
  (exec-path-from-shell-initialize))

When I start Emacs via the terminal I get the following error:

You appear to be setting environment variables ("MANPATH") in your .bashrc or .zshrc: those files are only read by interactive shells, so you should instead set environment variables in startup files like .profile, .bash_profile or .zshenv. Refer to your shell’s man page for more info.

However I do not have a . bashrc or . zshrc file.

When I open SpaceMacs as an app (i.e. not via terminal) I am not shown the error. Regardless how I open SpaceMacs I am not getting access to what's in my .bash_profile file.

My .bash_profile seems pretty standard:

[[ -s "$HOME/.profile" ]] && source "$HOME/.profile" # Load the default .profile

# Chruby
source /usr/local/share/chruby/chruby.sh
source /usr/local/share/chruby/auto.sh
chruby ruby-2.2.2

PS1="[\W]\$ "
alias ll="ls -lahG"
alias irbs="irb --simple-prompt"
alias rake="bundle exec rake"
alias bec="bundle exec cucumber"
alias ber="bundle exec spec"
alias pow="touch tmp/restart.txt"

alias pgstart="pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start"
alias pgrestart="pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log restart -m fast"
alias pgstart2="postgres -D /usr/local/var/postgres"
alias pgstop="pg_ctl -D /usr/local/var/postgres stop -s -m fast"
alias pgreset="rm /usr/local/var/postgres/postmaster.pid"

I have also tried commenting out the first 6 lines but I still get the same.

Any idea what I might be doing wrong?

[purcell]

@AstonJ:

I have installed the package and added the following lines to my init.el file:

(package-initialize) (when (memq window-system '(mac ns)) (exec-path-from-shell-initialize))

When I start Emacs via the terminal I get the following error:

You appear to be setting environment variables ("MANPATH") in your .bashrc or .zshrc: those files are only read by interactive shells, so you should instead set environment variables in startup files like .profile, .bash_profile or .zshenv. Refer to your shell’s man page for more info.

If you're starting it from the terminal, then window-system should be nil, and that block should not be getting executed. (And that's the intention of the block, because you don't need exec-path-from-shell from the terminal.) What am I missing here? How are you starting it?

[AstonJ]

Thanks for the reply @purcell

I usually start my code editors one of two ways, either by going to the directory in terminal and then typing emacs ., or, by simply dragging a folder onto the Emacs icon in the dock.

If it's any help, I installed and set-up SpaceMacs as per this guide: https://elixirforum.com/t/spacemacs-general-discussion-blog-posts-wiki/109

Although I think that's the pretty standard way of installing it on a Mac?

[AstonJ]

Hi again Steve, just a quick note to say it seems to be working now (I can use things like ll from my .bash_profile) and I fixed it by creating a .bashrc file and added . ~/.bash_profile to the end of it.

I am still getting the message on startup but only if I start from terminal:

You appear to be setting environment variables ("MANPATH") in your .bashrc or .zshrc: those files are only read by interactive shells, so you should instead set environment variables in startup files like .profile, .bash_profile or .zshenv. Refer to your shell’s man page for more info. Customize ‘exec-path-from-shell-arguments’ to remove "-i" when done, or disable ‘exec-path-from-shell-check-startup-files’ to disable this message.

Is this ok? Or should I investigate further in an attempt to stop this message from appearing?

[purcell]

@AstonJ Thanks. If you're not getting the message now, then I guess all is well enough, but it's still not clear why exec-path-from-shell-initialize was getting called by your startup scripts even though you weren't in a window-system Emacs instance. That's the root problem here, and creating .bash_profile has just worked around it, albeit harmlessly.

[AstonJ]

Thanks again for the reply Steve.

I'm still getting the message if I start from within Terminal. I'm not getting the message if I start from the dock though.

Btw, I had to create a .bashrc file as I already had a .bash_profile - that was after reading this from the emacs wiki:

Emacs shell environments behave differently from Terminal environments and in order to have correct environments like LANG=en_GB.utf-8 LC_ALL=en_GB.utf-8 or PATH= for sub-applications launched from Emacs like R, Octave, Gnuplot etc., set the environments not only in .bash_profile but in .bashrc and try (since Yosemite /etc/launchd.conf is no more consulted for security reasons).

It's done the trick anyway so I'm happy, unless you think I need to troubleshoot further? Could it be because I added:

(package-initialize)
(when (memq window-system '(mac ns))
  (exec-path-from-shell-initialize))

to my init.el file and perhaps should have added it to my .spacemacs file somewhere? (I think I read that we should only add customisations to the .spacemacs file). I'm new to emacs/spacemacs so not sure tbh.

[purcell]

It's done the trick anyway so I'm happy, unless you think I need to troubleshoot further? Could it be because I added:

(package-initialize) (when (memq window-system '(mac ns)) (exec-path-from-shell-initialize)) to my init.el file and perhaps should have added it to my .spacemacs file somewhere? (I think I read that we should only add customisations to the .spacemacs file). I'm new to emacs/spacemacs so not sure tbh.

Yeah, is it possible that the init.el file is being ignored, and spacemacs is calling exec-path-from-shell-initialize unconditionally?

[AstonJ]

I'm not sure tbh. I did remove those lines from init.el, and put them inside my .spacemacs file, but I still got the same thing.

Also slightly related, does exec-path-from-shell work for Eshells as well? (It's not for me - I don't have access to functions in my .bash_profile like how I didn't with the 'normal' emacs shell (which I get to in SpaceMacs by SPC ')

[AstonJ]

It looks like SpaceMacs include it by default :)

https://github.com/syl20bnr/spacemacs/blob/93e3b883c061c1fd685e9ef588b979704ca95c78/spacemacs/packages.el#L1032-L1035

https://github.com/syl20bnr/spacemacs/issues/2331

But I wonder why it's not working for me (by showing me the warning via terminal)