Skip to content

Conversation

@rspeicher
Copy link
Contributor

From the Zsh manual:

'.zshenv' is sourced on all invocations of the shell, unless the -f option is
set. It should contain commands to set the command search path, plus other
important environment variables. `.zshenv' should not contain commands that
produce output or assume the shell is attached to a tty.

`.zshrc' is sourced in interactive shells. It should contain commands to set up aliases,
functions, options, key bindings, etc.

So why is this important? Alfred workflows run in non-interactive shells. When the $PATH is set or rbenv is initialized in zshrc instead of zshenv, those workflows will not use the correct Ruby version and might not have access to certain bin files, such as those from $HOME/.bin/ or Homebrew.

I've created a simple workflow to demonstrate the problem if you'd like to see for yourselves. Install it and type rbenvtest into Alfred.

Before:
screen shot 2014-07-27 at 11 04 55 pm
After:
screen shot 2014-07-27 at 11 06 35 pm

From the [Zsh manual](http://zsh.sourceforge.net/Intro/intro_3.html):

> '.zshenv' is sourced on all invocations of the shell, unless the -f option is
> set. It should contain commands to set the command search path, plus other
> important environment variables. `.zshenv' should not contain commands that
> produce output or assume the shell is attached to a tty.

Why is this important? [Alfred](http://www.alfredapp.com/) workflows run in
non-interactive shells. When the `$PATH` is set, or `rbenv` is initialized, in
`zshrc` instead of `zshenv`, those workflows will not use the correct Ruby
version and might not have access to certain bin files, such as those from
`$HOME/.bin/` or Homebrew.
@rspeicher
Copy link
Contributor Author

Hmm, looks like /etc/zshrc on OSX is now modifying the PATH in a way we don't want, with /usr/bin coming before everything else. Not yet sure how to fix that. Apparently only a problem on Mountain Lion.

@mike-burns
Copy link
Contributor

This seems like a good idea. Has anyone run into problems with this change?

@gylaz
Copy link
Contributor

gylaz commented Aug 26, 2014

I have not tried this, but these changes look good.

@gylaz
Copy link
Contributor

gylaz commented Sep 12, 2014

Merged this as 6a1bd18. Thanks @tsigo!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants