OS X Mountain Lion: how does path_helper work?

Question

I installed rbenv through homebrew, and now I don\'t know why path_helper put ~/.rbenv/shims at the end of the path instead of the beginning. And most importantly, how did path_

Answer 1

The path_helper man page is incorrect. The man page says path_helper is appending /etc/paths.d onto the PATH. But actually, path_helper is APPENDing /etc/paths.d onto the list from /etc/paths and then effectively PREPENDing that result onto actual pre-existing PATH (as well as purging PATH of overridden duplicates from that list).

To be exact, speaking only of PATH for instance, what it does is:

1. read the list of paths in the file /etc/paths
2. APPEND onto it the lists of paths in the files in the directory /etc/paths.d
3. mutate the PATH variable to remove any items in the list
4. APPEND onto the list the value of the mutated PATH variable
5. Save this list as the new PATH

To rephrase this in pseudocode, what it's doing is:

1. NEWPATH = Read(/etc/paths)
2. NEWPATH = $NEWPATH +append+ Read(/etc/paths.d/*)
3. PATH = $PATH -minus- $NEWPATH
4. NEWPATH = $NEWPATH +append+ $PATH
5. PATH = $NEWPATH

What's treacherous about this is that, if you are manually configuring your PATH, it's probably in order to add components that override system path components. If path_helper gets called when you don't expect it, then it will undo your changes by putting the system-wide path components ahead of your path components.

How would path helper get called unexpectedly? For instance, it gets called by /etc/zshenv, which is called every time you start a zsh shell, whether it's a subshell, or a zsh instance called from another app like emacs, or whatever.

I've written it in more detail as an OpenRadar bug report on path_helper.