purcell/exec-path-from-shell

Make Emacs use the $PATH set up by the user's shell

exec-path-from-shell

A GNU Emacs library to ensure environment variables inside Emacs look the same as in the user's shell.

Motivation

Ever find that a command works in your shell, but not in Emacs?

This happens a lot on OS X, where an Emacs instance launched as a GUI app inherits a default minimal set of environment variables that are probably not the ones you see in a terminal window. Similarly, if you start Emacs as a daemon from systemd or launchd, it will run with a default set of environment variables.

This library solves this problem by copying important environment variables from the user's shell: it works by asking your shell to print out the variables of interest, then copying them into the Emacs environment.

Compatibility

Supported shells:

• zsh
• bash
• tcsh
• fish
• nu

Note that shell variables which have not been exported as environment variables (e.g. using the "export" keyword) may not be visible to exec-path-from-shell.

If you experience issues, enable the variable exec-path-from-shell-debug before runnin functions from the package: this will produce detailed logging in *Messages* about the shell command line and output.

Installation

Installable packages are available via MELPA: do M-x package-install RET exec-path-from-shell RET.

Alternatively, download the latest release or clone the repository, and install exec-path-from-shell.el with M-x package-install-file.

Usage

Add the following to your init.el (after calling package-initialize):

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

This sets $MANPATH, $PATH and exec-path from your shell, but only when executed in a GUI frame on OS X and Linux.

If you launch Emacs as a daemon from systemd or similar, you might like to use the following snippet:

(when (daemonp)
  (exec-path-from-shell-initialize))

You can copy values of other environment variables by customizing exec-path-from-shell-variables before invoking exec-path-from-shell-initialize, or by calling exec-path-from-shell-copy-env, e.g.:

(exec-path-from-shell-copy-env "PYTHONPATH")

This function may also be called interactively.

The author uses the following configuration snippet before calling exec-path-from-shell-initialize:

(require 'exec-path-from-shell)
(dolist (var '("SSH_AUTH_SOCK" "SSH_AGENT_PID" "GPG_AGENT_INFO" "LANG" "LC_CTYPE" "NIX_SSL_CERT_FILE" "NIX_PATH"))
  (add-to-list 'exec-path-from-shell-variables var))

Setting up your shell startup files correctly

Note that your shell will inherit Emacs's environment variables when it is run by exec-path-from-shell -- to avoid surprises your config files should therefore set the environment variables to their exact desired final values, i.e. don't do this:

export PATH=/usr/local/bin:$PATH

but instead do this:

export PATH=/usr/local/bin:/usr/bin:/bin

To be safe, exec-path-from-shell starts an interactive (and login) shell by default, but this can be much slower than necessary. Interactive shells often have fancy features enabled that are only helpful when one interacts directly with the shell, and this can frequently cause startup time to exceed 750ms. This can be avoided:

• Follow best practice by setting your environment variables so that they are available to both interactive and non-interactive shells. In practical terms, for most people this means setting them in ~/.profile, ~/.bash_profile, ~/.zshenv instead of ~/.bashrc and ~/.zshrc.
• Once a non-interactive shell sets your environment variables correctly, adjust exec-path-from-shell-arguments appropriately (often to nil) before calling exec-path-from-shell-initialize so that it will start a non-interactive shell.

To learn more about how popular shells load start-up files, read this helpful article.

Making exec-path-from-shell faster

If evaluation takes more than exec-path-from-shell-warn-duration-millis (500ms by default) then exec-path-from-shell will print a warning.

• Non-interactive shells start up faster. Follow the steps in the section above so that you can run your shell without -i and still get the right environment variable settings. When "-i" is then removed from exec-path-from-shell-arguments, this package becomes more efficient.
• Invoking the shell has a non-trivial overhead in any case. Don't call exec-path-from-shell-copy-env repeatedly, since each invocation starts a shell. Instead, set exec-path-from-shell-variables to the full list of vars you want, and call exec-path-from-shell-initialize once.

Further help

• C-h f exec-path-from-shell-initialize
• C-h f exec-path-from-shell-copy-env

---

💝 Support this project and my other Open Source work via Patreon

💼 LinkedIn profile

✍ sanityinc.com

🐦 @sanityinc

exec-path-from-shell's Issues

Copy all environment variables

It would be convenient to be able to copy all environment variables without specifying them individually. Could the list of environment variables be obtained by parsing the output of env?

How to test if an environment variable exists?

Hi guys,

I want to know how to test if an environment variable exists and I only want to "copy" it when it exists. I want this is because I need to work on several computers and they have slightly different environment variables set.

Thanks.

support emacs daemon from launchd

It works perfectly for GUI emacs. Is it possible to support emacs daemon that launched from ~/Library/LaunchAgents/homebrew.mxcl.emacs.plist?

exec-path-from-shell with req-package (use-package)

I'm not sure if I should open it here, or at req-package, but thought I should ask if there's any reason why this does not work?

  (req-package exec-path-from-shell                                                                                     
    :if (memq window-system '(mac ns))                                                                                  
    :init                                                                                                               
    (progn                                                                                                              
      (exec-path-from-shell-initialize)                                                                                 
      (exec-path-from-shell-copy-env "ANDROID_HOME"))) 

It works fine if I evaluate the expressions manually, but not from init.el, for some reason.
I've tried also without the condition, this block never seem to get evaluated at all.

Speed issue with exec-path-from-shell-initialize

Hello Steve,

First of all, many thanks for this excellent package. However, I realize that is slows down my startup time significantly. I have benchmarked using benchmark-init and here is what I've got.

On the top is the loading time per require call, on the bottom is the contents of the prolusion-eshell file that uses exec-path-from-shell-initialize. It is 6 times as long as loading my theme.

Is there any way I can speed it up ? Maybe with an autoload at least to defer its loading time when I open an eshell ?

Thanks !

Fails with tcsh when a variable is unset

tcsh complains if a variable is unset, so asking tcsh to print a set of variable values can fail completely if one of those variables is unset.

See bbatsov/prelude#448

Option to disable -i

In a proper Zsh setup with .zshenv, -i is redundant. Hence, it'd be nice to have a way to remove -i from the shell command line used by this package.

Before opening a PR, I'd like to discuss the implementation first, since we can essentially choose between to different approaches:

• Only make -i customizables with a boolean flag.
• Make the entire command line customizable, using a list option, whose default is ("-i").

I'd favour the latter, but I'd like to get your OK before implementing it.

run vim in emacs term mode

I have tried to run vim in emacs many times
the result is also can't be satisfied for me
I check the variable in term mode echo $TERM
it print out eterm-color
then the same step for mac terminal echo $TERM
it print out xterm-256color

---

something I already use this package to add TERM variable

emacs hangs when typing cpp codes

emacs hangs (for several seconds, sometimes even couple of minutes) frequently when I am typing some cpp codes. Is this caused by auto-complete or anything else? Is there any way to work around? Thanks!

Empty variables break initialization

Adding a variable which is unset or blank to exec-path-from-shell-variables results in PATH being blank. I tested this with the following ~/.emacs file.

(package-initialize)
(require 'exec-path-from-shell)
(add-to-list 'exec-path-from-shell-variables "NONEXISTENT")
(exec-path-from-shell-initialize)

exec-path-from-shell-getenvs fails if $MANPATH is not set and set -e nounset

exec-path-from-shell-getenvs fails if MANPATHis not set in the shell and we have set -e nounset somewhere in the bash startup scripts.

Problem occurs e. g. on OSX while installation of emacs-prelude (see also bbatsov/prelude#448).

Stacktrace:

Debugger entered--Lisp error: (error "Non-zero exit code from shell /usr/local/bin/bash invoked with args (\"-l\" \"-i\" \"-c\" \"/usr/bin/printf '__RESULT\\\\000%s\\\\000%s' \\\"$PATH\\\" \\\"$MANPATH\\\"\")")
  signal(error ("Non-zero exit code from shell /usr/local/bin/bash invoked with args (\"-l\" \"-i\" \"-c\" \"/usr/bin/printf '__RESULT\\\\000%s\\\\000%s' \\\"$PATH\\\" \\\"$MANPATH\\\"\")"))
  error("Non-zero exit code from shell %s invoked with args %S" "/usr/local/bin/bash" ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"$PATH\" \"$MANPATH\""))
  exec-path-from-shell-printf("%s\\000%s" ("$PATH" "$MANPATH"))
  exec-path-from-shell-getenvs(("PATH" "MANPATH"))
  exec-path-from-shell-copy-envs(("PATH" "MANPATH"))
  exec-path-from-shell-initialize()
  eval-buffer(#<buffer  *load*-95044> nil "/Volumes/HDD/home/joern/.emacs.d/core/prelude-osx.el" nil t)  ; Reading at buffer position 1320
  load-with-code-conversion("/Volumes/HDD/home/joern/.emacs.d/core/prelude-osx.el" "/Volumes/HDD/home/joern/.emacs.d/core/prelude-osx.el" nil t)
  require(prelude-osx)
  (progn (require (quote prelude-osx)))
  (if (eq system-type (quote darwin)) (progn (require (quote prelude-osx))))
  eval-buffer(#<buffer  *load*> nil "/Volumes/HDD/home/joern/.emacs.d/init.el" nil t)  ; Reading at buffer position 4445
  load-with-code-conversion("/Volumes/HDD/home/joern/.emacs.d/init.el" "/Volumes/HDD/home/joern/.emacs.d/init.el" t t)
  load("/Volumes/HDD/home/joern/.emacs.d/init" t t)
  #[0 \205\262^@        \306=\203^Q^@\30\310Q\202;^@    \311=\204^^^@\30\312Q\202;^@\313\307\314\315#\203*^@\316\202;^@\313\307\314\317#\203:^@\320\nB^R\321\202;^@\316\322^S\323^A\322\211#\210^K\322=\203a^@\324\325\326\30\327Q!\"\323^A\322\211#\210^K\322=\203`^@^A^S\210^K\203\243^@\330^K!\331\232\203\243^@\332^K!\211\333P\334^A!\203}^@\211\202\210^@\334^B!\203\207^@^A\202\210^@\314\262^B^A\203\241^@\335^B^K\"\203\237^@\336\337^C^K#\210\340\341!\210^A^S\266^B\f?\205\260^@\314^]\323\342\322\211#)\262^A\207" [init-file-user system-type delayed-warnings-list user-init-file inhibit-default-init inhibit-startup-screen ms-dos "~" "/_emacs" windows-nt "/.emacs" directory-files nil "^\\.emacs\\(\\.elc?\\)?$" "~/.emacs" "^_emacs\\(\\.elc?\\)?$" (initialization "`_emacs' init file is deprecated, please use `.emacs'") "~/_emacs" t load expand-file-name "init" file-name-as-directory "/.emacs.d" file-name-extension "elc" file-name-sans-extension ".el" file-exists-p file-newer-than-file-p message "Warning: %s is newer than %s" sit-for 1 "default"] 7 "\n\n(fn)"]()
  command-line()
  normal-top-level()

Conflicts with fish-shell

The problem is fish-shell uses space as a separator inside PATH env var.
The package can't parse it and in the end exec-path has just one element which is just a copy of PATH env var.

My ad-hoc solution is appending this to my init.el:

(setq exec-path (split-string (car exec-path)))

Calling exec-path-from-shell-initialize freezes Spacemacs on FreeBSD

Running (exec-path-from-shell-initialize) on FreeBSD causes Spacemacs to freeze during startup (bug syl20bnr/spacemacs#3887). The started bash process seems to be stuck, running at 100% and never returning. The full arguments of the process according to ps www are:

/usr/local/bin/bash -l -i -c /usr/bin/printf '__RESULT\\000%s\\000%s' "${PATH-39a3b6c118441cd3550bf60cd83b0bba}" "${MANPATH-39a3b6c118441cd3550bf60cd83b0bba}"

Supoort xonsh

Could support be added for xonsh? It would be fine, but xonsh is written in python and therfore doesn't support null bytes.

Error on Windows

I'm not sure how to best handle this, but when on Windows you'd get something like:

Error (use-package): exec-path-from-shell :config: Non-zero exit code from shell C:/Users/bozhi/emacs-24.5/libexec/emacs/24.5/i686-pc-mingw32/cmdproxy.exe invoked with args ("-l" "-i" "-c" "printf '__RESULT\\000%s\\000%s' \"${PATH-f0e5ce552c1531f4ab5b890d638405b1}\" \"${MANPATH-f0e5ce552c1531f4ab5b890d638405b1}\"").  Output was:
"'printf' is not recognized as an internal or external command,
operable program or batch file.
"

I can disable the package in my config, or can behave differently in such cases (which seems like a better idea in general).

Support for fish shell (path-separator)

With fish as the default shell, on Linux (ubuntu) I need to do this before using exec-path-from-shell, or else `exec-path' gets a single string containing all the subdirs in $PATH:

(when (file-name-nondirectory (getenv "SHELL")) "fish"
   (setq path-separator " ")) 

...
(exec-path-from-shell-initialize)
...

Didn't test this on OSX, but I'm guessing it's the same. Is this something exec-path-from-shell should handle?

BTW - I'm using exec-path-from-shell when running emacs as server in a user session Upstart job.

AFAIK, Upstart execs jobs off a minimal shell ('sh'). When in emacs(client) though, (getenv "SHELL") returns 'fish', so I'm not sure where handling of path-saparator goes wrong, if at all.

execute bash ~/.bashrc or zsh ~/.zshrc

how execute bash ~/.bashrc or zsh ~/.zshrc in emacs, and copy then to emacs env?

Causes (Cocoa) Emacs to fail on OS X 10.9 (w/ bash shell when MANPAGE env var is empty)

I updated my packages via ELPA and MELPA, so I should have the tcsh-specific fix for this. I'm using bash, though.

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("" nil 0)
  split-string(nil "")
  exec-path-from-shell-getenvs(("PATH" "MANPATH"))
  exec-path-from-shell-copy-envs(("PATH" "MANPATH"))
  exec-path-from-shell-initialize()
  byte-code("\301\302!\210\303\304!\210\305 \210\306�\301\207" [ns-function-modifier prelude-require-packages (exec-path-from-shell) require exec-path-from-shell exec-path-from-shell-initialize hyper] 2)
  require(prelude-osx)
  byte-code("\306\307�\"\210\306\307    \"\210\306\307\n\"\210\310\n!\210\311�\312\f!\203)\313\314\f\"\210\315\316\317\f\320\321#\"\210\313\322!\210\323\324!\210\323\325!\210\323\326!\210\323\327!\210\323\330!\210\323\331!\210
\332=\203O\323\333!\210\313\334!\210\312�%!\203_\316�%!\210\335\336�&\"�'\312�&!\203}\313\314�&\"\210\315\316\317�&\320\321#\"\210\313\337�(\"\210\340\341\342\343\344#!\207" [prelude-core-dir prelude-modules-dir prelude-vendor-dir gc-cons-threshold prelude-personal-preload-dir system-type add-to-list load-path prelude-add-subfolders-to-load-path 50000000 file-exists-p message "Loading personal configuration files in %s..." mapc load directory-files t "^[^#].*el$" "Loading Prelude's core..." require prelude-packages prelude-ui prelude-core prelude-mode prelude-editor prelude-global-keybindings darwin prelude-osx "Loading Prelude's modules..." expand-file-name "custom.el" "Prelude is ready to do thy bidding, Master %s!" prelude-eval-after-init run-at-time 5 nil prelude-tip-of-the-day prelude-modules-file prelude-personal-dir custom-file current-user] 6)
  load("/Users/gaelan/.emacs.d/init" t t)
  #[0 "�\205\262    \306=\203�\307�\310Q\202;   \311=\204�\307�\312Q\202;\313\307\314\315#\203*\316\202;\313\307\314\317#\203:\320\nB�\321\202;\316\322�\323�\322\211#\210�\322=\203a\324\325\326\307�\327Q!\"\323�\322\211#\210�\322=\203`��\210�\203\243\330�!\331\232\203\243\332�!\211\333P\334�!\203}\211\202\210\334�!\203\207�\202\210\314\262��\203\241\335��\"\203\237\336\337��#\210\340\341!\210��\266�\f?\205\260\314�\323\342\322\211#)\262�\207" [init-file-user system-type delayed-warnings-list user-init-file inhibit-default-init inhibit-startup-screen ms-dos "~" "/_emacs" windows-nt "/.emacs" directory-files nil "^\\.emacs\\(\\.elc?\\)?$" "~/.emacs" "^_emacs\\(\\.elc?\\)?$" (initialization "`_emacs' init file is deprecated, please use `.emacs'") "~/_emacs" t load expand-file-name "init" file-name-as-directory "/.emacs.d" file-name-extension "elc" file-name-sans-extension ".el" file-exists-p file-newer-than-file-p message "Warning: %s is newer than %s" sit-for 1 "default"] 7 "\n\n(fn)"]()
  command-line()
  normal-top-level()

Printf error with Fish

I get the following error when fish is my defined shell:

Error (use-package): exec-path-from-shell :init: Expected printf output from shell, but got: ""

bash throws "cannot set terminal process group" error

for details,
http://unix.stackexchange.com/questions/208159/bash-throws-cannot-set-terminal-process-group-error

does the shell need -i argument, just to run a single command? are not -i and -l options meant for two diametrically opposite features?

and is there a quick fix for this error on my local system?

zsh should maybe not use the `-l` flag

zsh sources ~/.zshenv before the profile files (see here for loading order) which might overwrite the PATH. This happened to me on Arch because /etc/profile contained:

PATH="/usr/local/sbin:/usr/local/bin:/usr/bin"
export PATH

Expected printf but got blep

Error (use-package): exec-path-from-shell :init: Expected printf output from shell, but got: ""
Warning (initialization): An error occurred while loading ‘/home/howdoicomputer/.emacs.d/init.el’:

error: Expected printf output from shell, but got: ""

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace.

Sad faces.

Fail gracefully if SHELL is not defined.

Seems that some environments don't pass SHELL.

This causes the predicate which checks for standard shell to fail with a stringp / nil type error.

It does not understand env var in `if-else` branch

My env configuration is based on different os version checking, e.g.,

# shared
export A="a"
export B="b"
# ....
if [[ `uname` == 'Linux' ]]; then
  export C="c"
  export D="d"
  # ....
else
  export E="e"
  export F="f"
  # ....
fi

But, it does not contain all of the env in the if-else block, only global(A, B) is accepted. It works well in shells.

Tested on macOS 10.12.3 and spacemacs [email protected]

Shell / Compile etc PATH not set after running exec-path-from-shell-initialize

Hi Steve, having some weird issues with PATH on shell-command and compile.

The shell PATH when in the terminal is :

/Users/neo/.rvm/gems/ruby-2.0.0-p353/bin:/Users/neo/.rvm/gems/ruby-2.0.0-p353@global/bin:/Users/neo/.rvm/rubies/ruby-2.0.0-p353/bin:/usr/local/heroku/bin:./bin:/Users/neo/bin:/usr/local/bin:/usr/local/sbin:/usr/local/share/npm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Users/neo/.rvm/bin

However, in Emacs (non-daemon OSX/GUI session) after running exec-path-from-shell-initialize M-x compile echo $PATH reports:

./bin:/Users/neo/bin:/usr/local/bin:/usr/local/sbin:/usr/local/share/npm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/heroku/bin:/Users/neo/.rvm/gems/ruby-2.0.0-p353/bin:/Users/neo/.rvm/gems/ruby-2.0.0-p353@global/bin:/Users/neo/.rvm/rubies/ruby-2.0.0-p353/bin:/Users/neo/.rvm/bin

Is there something else I need to do?

After (exec-path-from-shell-variables "UNSET_VARIABLE"), (getenv "UNSET_VARIABLE") returns "" rather than nil

My expectation is that environment variables that are not set in the shell would not be set in emacs, even if they're explicitly included in the args to exec-path-from-shell-variables.

Nine times out of ten this won't matter, but this causes problems with, e.g., awscli. I usually set AWS_PROFILE to switch accounts, though I sometimes instead use AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (this could vary, e.g., based on the machine on which I'm running, but really I'd just prefer not to have to edit both my emacs init and .profile). The various AWS utilties and libraries all react badly to this, ignoring AWS_PROFILE if the other two variables are set to "".

I think one solution to this is to do something like ${VAR:+"undefined"} when printing instead of ${VAR-} and filtering "undefined" out of the results in exec-path-from-shell-getenvs, but I don't really know what I'm talking about 😄

Fish shell and Environment variables

I decided to try Fish shell after using ZSH for a while. Everything was fine in ZSH but now every time I start Emacs, I get the warning You appear to be setting environment variables ("PATH") in your .bashrc or .zshenv ... with the suggestion that I instead set it in .zshenv or .bash_profile etc.

The thing is fish has only one config file as far as I know which is config.fish. Do you know how to set the PATH in fish so as to get rid of the warning. I have tried moving setting into different folders under ~/.config/fish without success. I appreciate that you may not use Fish Shell and as such can't help.

exec-path paths order reversed

I might be missing the point, but couldn't find a solution looking through reported issues.

I'm trying to get pyenv to work transparently in emacs, but it looks like the path order gets reversed when using exec-path-from shell.

In the terminal I will have:

$ echo $PATH
/usr/local/opt/pyenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

While when using exec-path-from-shell-initialize, exec-path becomes

("/usr/local/bin/" "/usr/bin/" "/bin/" "/usr/sbin/" "/sbin/" "/usr/local/opt/pyenv/shims/" "/usr/local/Cellar/emacs/24.3/libexec/emacs/24.\
3/x86_64-apple-darwin13.2.0/")

To compare, I evaluated exec-path in non GUI emacs, which shows the the PATH was imported as is:

("/usr/local/opt/pyenv/shims" "/usr/local/bin" "/usr/bin" "/bin" "/usr/sbin" "/sbin" "/usr/local/Cellar/emacs/24.3/libexec/emacs/24.3/x86_\
64-apple-darwin13.2.0")

In GUI emacs, when I run execp-path-from-shell-initialize and eval exec-path manually, PATH seems to be setup correctly as well...

Getting Error :init: Expected printf output from shell

When launching spacemacs which uses exec-path-from-shell I get the following error from it:

Error (use-package): exec-path-from-shell :init: Expected printf output from shell, but got: "%  

�[01;36muser@cloud] �[00m"

I'm sure it's due to some of the things I do or source from my .zshrc, but I'm not sure what, and I'd rather exec-path-from-shell could handle the customization of my zsh, then me having to get rid of it.

Anyone got this problem before?

P.S.: Same thing happens if I manually run (exec-path-from-shell-initialize) or (exec-path-from-shell-copy-env) for any variable.

Broken with xonsh

When running exec-path-from-shell from macOS Sierra and xonsh as my default shell, I get the following error:

Warning (initialization): An error occurred while loading ‘/Users/autrilla/.emacs.d/init.el’:

error: Non-zero exit code from shell /usr/local/bin/xonsh invoked with args ("-l" "-i" "-c" "/usr/bin/printf '__RESULT\\000%s\\000%s' \"${PATH-ed5bedb9d1d7d2085e34acc2d4a2e61a}\" \"${MANPATH-ed5bedb9d1d7d2085e34acc2d4a2e61a}\"").  Output was:
"Traceback (most recent call last):
  File \"/usr/local/bin/xonsh\", line 3, in <module>
    main()
  File \"/usr/local/Cellar/xonsh/0.4.6/libexec/lib/python3.5/site-packages/xonsh/__amalgam__.py\", line 17488, in main
    run_code_with_cache(args.command.lstrip(), shell.execer, mode='single')
  File \"/usr/local/Cellar/xonsh/0.4.6/libexec/lib/python3.5/site-packages/xonsh/__amalgam__.py\", line 2086, in run_code_with_cache
    run_compiled_code(ccode, glb, loc, mode)
  File \"/usr/local/Cellar/xonsh/0.4.6/libexec/lib/python3.5/site-packages/xonsh/__amalgam__.py\", line 1961, in run_compiled_code
    func(code, glb, loc)
  File \"ce9d521e89dbcd8a2350b8da8bc47901\", line 1, in <module>
  File \"/usr/local/Cellar/xonsh/0.4.6/libexec/lib/python3.5/site-packages/xonsh/__amalgam__.py\", line 16462, in subproc_captured_hiddenobject
    return run_subproc(cmds, captured='hiddenobject')
  File \"/usr/local/Cellar/xonsh/0.4.6/libexec/lib/python3.5/site-packages/xonsh/__amalgam__.py\", line 16325, in run_subproc
    **subproc_kwargs)
  File \"/usr/local/Cellar/python3/3.5.2_1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/subprocess.py\", line 947, in __init__
    restore_signals, start_new_session)
  File \"/usr/local/Cellar/python3/3.5.2_1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/subprocess.py\", line 1490, in _execute_child
    restore_signals, start_new_session, preexec_fn)
ValueError: embedded null byte
"

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace.

~ $ (getenv "SHELL")
/usr/local/bin/xonsh

Compatibility issue with fish 2.5

As reported in a spacemacs issue thread, there is an issue with the latest version of fish, resulting in the message:

Error (use-package): exec-path-from-shell :init: Expected printf output from shell, but got: ""

Setting zsh path array no longer works

This snippet of code worked before (in my zshrc), but now it doesn't appear to grab the path updates correctly now that it's in zshenv. Note that if I echo $PATH right after setting path in my zshenv, it shows the correct value:
/home/belak/bin:/home/belak/go/bin:/home/belak/.rbenv/shims:/home/belak/.rbenv/bin:/home/belak/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin

# Automatically remove duplicates from these arrays
typeset -U path cdpath fpath manpath

# Golang stuff
export GOPATH=$HOME/go

# Add our custom stuff
fpath=("$HOME/.belak/zsh" $fpath)
path=("$HOME/bin" "$GOPATH/bin" "$HOME/.rbenv/shims" "$HOME/.rbenv/bin" "$HOME/.local/bin" $path)

Initialize during package load?

What would you say to the proposition of calling exec-path-from-shell-initialize somehow when loading the package? I only ask because the whole OS X window system PATH malarkey caused some confusion for me here: djcb/mu#511

Probably not worth the effort and probable problems it would cause, but just thought I'd ask.

Env variable not copied

Hello,

I have a .profile, sourced from my .zshrc.
In .profile I export a value for GOPATH

export GOPATH="$HOME/Development/Go/gopath/"

Running exec-path-from-shell-copy-env in emacs doesn't seem to work

(exec-path-from-shell-copy-env "GOPATH)
(getenv "GOPATH") ;; => nil

Am I doing something wrong?

melpa package not working for emacs 24.5

Hi, I can get this to work by putting the .el file on my path and adding the initialization code to my .emacs as suggested in the comments at the top of the file. but when I use list-packages to list and install the package using elpa, installation goes smoothly, but then it doesn't seem to change the path/exec-path, so am not sure it is activated at all. thanks for a great package... E

OS X warning from default bashrc

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.

Make SHELL configurable?

I have my system set up such that I can use both bash and fish, with SHELL being set to fish since I use that by default. exec-path-from-shell seems to have some issues with fish though, so I would like to override the shell used by exec-path-from-shell. Can we add a variable to specify an explicit override?

Consider removing "-i" from the shell startup args

See bbatsov/prelude#625

Might cause breakage if people are setting env vars in files which are only sourced by their shell in interactive mode.

Not working

I'm having issues with my ZSH shell $PATH and the $PATH from within Emacs on OSX. I've created a Stackoverflow post where I explain all the details. I've tried using your module but it does not work, it changes nothing on the $PATH variable.

On top of that, running your module has the side effect of messing up or clearing my .zprofile settings of export TERM=xterm-256color since my theme appears with 16 colours when it runs.

Autoload issue?

I'm a user of Emacs Prelude on OS X, and I've been getting the error "Symbol's function definition is void: exec-path-from-shell-initialize".

I can fix this via a (require 'exec-path-from-shell) command, but this shouldn't be necessary.

Here's my exec-path-from-shell-autoloads.el file in its entirety:

;;; exec-path-from-shell-autoloads.el --- automatically extracted autoloads
;;
;;; Code:


(provide 'exec-path-from-shell-autoloads)
;; Local Variables:
;; version-control: never
;; no-byte-compile: t
;; no-update-autoloads: t
;; coding: utf-8
;; End:
;;; exec-path-from-shell-autoloads.el ends here

Incompatability with bash session saving in OS X El Capitan

I have noticed that when using emacs with spacemacs my MANPATH variable (which I have not set) is set to a garbage string.

97e625ce3d2a2db7f21b445e5a217d32Saving session...^[[?1034hcompleted.

I have traced this bug to exec-path-from-shell library. In particular in the function exec-path-from-shell-getenvs there is a test performed to determine if an environment variable is set (on lines 168--169):

(unless (string-equal random-default value)
    value))

This test produces a false positive for MANPATH, as it is comparing random-default to value which is equal to random-default with Saving session...^[[?1034hcompleted. concatenated onto the end. This Saving session...^[[?1034hcompleted. message was introduced in El Capitan and is specific to some sort of "session saving" for bash.

One quick fix is to replace lines 168--169 with:

(unless (string-prefix-p random-default value)
    value))

However, if possible it would be better to use a more robust method to check if a variable is set.

Copying a virtualenv's PYTHONPATH

Hello,

I have a $PYTHONPATH being set when a Python virtualenv is being activated. When I activate the virtualenv in Emacs using pyenv-mode, I am calling exec-path-from-shell-copy-env to copy the variable, but it isn't getting copied. Is there anything else that I will need to do, to get it to work with virtualenvs? Has anyone had any success using this package with virtualenvs?

does not work with bashdb installed

For long and largely silly reasons, I had previously installed bashdb on my laptop (a step debugger for bash... yes there really were reasons). When I tried to get exec-path-from-shell working on that machine I kept getting issues during the initialize about a bad bash ioctl.

Uninstalling bashdb fixed it. But it seemed worth reporting that there is an incompatibility with that.

Ubuntu 16.10, x86_64, all the latest patches.

package-install-file fails

I tried the Installation step after downloading and saving the file.

The installation instructions are wrong (M-x package-install-from-file should be M-x package-install-file)

After running M-x package-install-file, I got an error:

package-buffer-info: Package lacks a "Version" or "Package-Version" header

M-x emacs-version reports:

GNU Emacs 24.5.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21) of 2015-04-10 on builder10-9.porkrind.org

Runs slowly

Even with exec-path-from-shell-check-startup-files set to nil, this takes a second or more to run on my MBP. Is it this slow for everyone?

package install problems

M-x package-install-file ~/Downloads/exec-path-from-shell-1.6/exec-path-from-file.el
~~>
Package lacks a "Version" or "Package-version" header.

It also is not listed in "list-packages" under marmalade. Emacs 24.2.1 on Mac OSX the latest

incompatible with shells started via 'exec shell' in ~/.bashrc

If a shell is started at the end of ~/.bashrc (e.g., exec fish), then it causes spacemacs to start with an error:

Error (use-package): exec-path-from-shell :init: Expected printf output from shell, but got: "bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

Support dired-do-shell-command

When the program is on a custom path, dired-do-shell-command can't find it. dired-do-shell-command must have been using another path setting.

Take care of the possible absence of SHELL env.

Not sure about the fact that it should be handled in the package but I mention it in case it can.
More info at syl20bnr/spacemacs#219.

PATH declarations + exec-path-from-shell causes Tramp to hang

I added two new lines to my .bashrc [so that Bash can find my Go programs][1]:

GOROOT=/Users/jay/work 
PATH=$PATH:$GOROOT/bin 

But as a result, when I launch Emacs, Emacs hangs for several minutes and I get this error:

Tramp: Opening connection for bin using ssh...
Tramp: Sending command `exec ssh   -o ControlMaster=auto -o ControlPath='tramp.%C' -o ControlPersist=no -e none bin'
Tramp: Waiting for prompts from remote shell...
Tramp failed to connect.  If this happens repeatedly, try
    `M-x tramp-cleanup-this-connection'
Tramp: Waiting for prompts from remote shell...failed
Tramp: Opening connection for bin using ssh...failed

Disabling exec-path-from-shell resolved the issue:
http://emacs.stackexchange.com/questions/24159/tramp-waiting-for-prompts-from-remote-shell?noredirect=1#comment37054_24159

How do I resolve this error without disabling exec-path-from-shell?