This reverts 15de0bc, which I find to be harmful advice. El Capitan finally fixed/etc/zshenv to be called /etc/zprofile, and now you're suggesting to users to undo that fix without understanding of what they were doing?
El Capitan's /etc/zprofile calls path_helper, which is a OS X utility to initialize the system PATH. This is meant to run for login shells before any user PATH configuration. Therefore, /etc/zprofile is the perfect place to call it.
If /etc/zshenv called path_helper, like it did in older versions of OS X, then it would reorder PATH on all subsequent invocations of zsh, such as nested shells (e.g. running zsh from bash) or executables with zsh in their shebang. This was a bug, and resulted in failed commands and much confusion to users, who thought that path_helper is the main culprit and some used sudo to disable this utility, further messing up their system.
After reverting the offending documentation addition, my approach to solving problem (as implemented in this PR) is as follows:
Detect broken /etc/zshenv (OS X versions pre-El Capitan) and suggest the user renames them to zprofile.
Move .zshenv configuration (runs too early) to .zshrc where it runs only once for interactive shells, and after system PATH is now set up.
Stop suggesting in documentation that users use .zshenv. Instead, most typical user tweaks for their environment need to be in .zshrc, such as PATH edits.
Support .zshenv.local for backwards compatibility, but issue a warning on stderr when its configuration changes PATH, and suggest to user that it gets moved to .zshrc.local.
Please observe more information for each of my commits from their commit messages.
The benefits of this approach:
Doesn't use sudo to make harmful changes to the system, except for fixing a OS X bug. El Capitan users don't have to fix anything.
Avoids excessive and unnecessary usage of .zshenv, thus speeding up non-interactive zsh executables.
Uses .zshrc as it should be used: to host configuration for interactive shells.
Helps people transition from the state where everything was messed up (OS X bug, user PATH changes in ~/.zshenv) to the preferred long-term approach.
Note that this probably "breaks" Alfred workflows again as pointed out in #289. However, Alfred purposely doesn't start shells in login mode so that they're isolated from user's terminal environment. Alfred's own documentation states that workflows should not depend on any particular setup in the user's environment. If someone makes private workflows for themselves and needs to use rbenv version switching, they should setup rbenv within the workflow.
This reverts 15de0bc, which I find to be harmful advice. El Capitan finally fixed
/etc/zshenvto be called/etc/zprofile, and now you're suggesting to users to undo that fix without understanding of what they were doing?El Capitan's
/etc/zprofilecallspath_helper, which is a OS X utility to initialize the system PATH. This is meant to run for login shells before any user PATH configuration. Therefore,/etc/zprofileis the perfect place to call it.If
/etc/zshenvcalledpath_helper, like it did in older versions of OS X, then it would reorder PATH on all subsequent invocations of zsh, such as nested shells (e.g. runningzshfrom bash) or executables withzshin their shebang. This was a bug, and resulted in failed commands and much confusion to users, who thought thatpath_helperis the main culprit and some used sudo to disable this utility, further messing up their system.After reverting the offending documentation addition, my approach to solving problem (as implemented in this PR) is as follows:
/etc/zshenv(OS X versions pre-El Capitan) and suggest the user renames them tozprofile..zshenvconfiguration (runs too early) to.zshrcwhere it runs only once for interactive shells, and after system PATH is now set up..zshenv. Instead, most typical user tweaks for their environment need to be in.zshrc, such as PATH edits..zshenv.localfor backwards compatibility, but issue a warning on stderr when its configuration changes PATH, and suggest to user that it gets moved to.zshrc.local.Please observe more information for each of my commits from their commit messages.
The benefits of this approach:
sudoto make harmful changes to the system, except for fixing a OS X bug. El Capitan users don't have to fix anything..zshenv, thus speeding up non-interactive zsh executables..zshrcas it should be used: to host configuration for interactive shells.~/.zshenv) to the preferred long-term approach.References #307, #421, closes #423
Note that this probably "breaks" Alfred workflows again as pointed out in #289. However, Alfred purposely doesn't start shells in login mode so that they're isolated from user's terminal environment. Alfred's own documentation states that workflows should not depend on any particular setup in the user's environment. If someone makes private workflows for themselves and needs to use rbenv version switching, they should setup rbenv within the workflow.
Further reading:
/cc @geoffharcourt @ventsislaf @reshleman