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_helper get this information?
According to the man page of path_helper, it reads entries from /etc/paths and from files in /etc/paths.d. But I cannot find the string ".rbenv/shims" there.
~% cat /etc/paths
/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin
~% ls -la /etc/paths.d
total 0
drwxr-xr-x 2 root wheel 68 Jun 21 03:16 .
drwxr-xr-x 107 root wheel 3638 Sep 10 09:59 ..
~% /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/gordon/.rbenv/shims"; export PATH;
The default PATH and MANPATH values are in /etc/paths and /etc/manpaths . And also the path-helper reads files in the etc/paths.
Setting the PATH Variable Permanently To do this, you need to access the shell's configuration or profile file and add the program's path to it. Depending on the macOS version you're running on your Mac, this can be done via either the bash shell or zsh (z shell).
PATH is a system-level variable that holds a list of directories. When you enter a command in the terminal, it's shorthand for a program with the same name. The system looks in each of the PATH directories for the program corresponding to the command. When it finds a matching program, it runs it.
I suspect that your .bash_profile
or .bashrc
is adding
.rbenv/shims
to your PATH, and that is running at some point before
path_helper
is invoked during the shell start-up.
The man page for path_helper opens with:
The path_helper utility reads the contents of the files in the directo-
ries /etc/paths.d and /etc/manpaths.d and appends their contents to the
PATH and MANPATH environment variables respectively.
The crucial point here is that the path_helper utility is intended to
add contents to an existing PATH
setting, not replace them. (And in
actuality, what it really does is prepend contents, not append them,
which matters for PATH
variables...)
So, if I start out with an entry on my PATH
, the setting generated by
path_helper will ensure that entry continues on the PATH
it generates.
% echo $SHELL
/bin/bash
% uname
Darwin
% /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"; export PATH;
% PATH="" /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"; export PATH;
% PATH=foo /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo"; export PATH;
Note that foo
has been included in my PATH in the last line, even though
the contents of /etc/paths
and /etc/paths.d/*
have not changed.
At the same time, the path_helper utility also seems to be careful not
to produce paths with duplicate entries; it removes duplicate entries
after concatenating /etc/paths
and /etc/paths.d/*
and the current
PATH
.
This latter detail can be especially confusing since it can cause
entry reorderings compared to the original PATH
setting (!).
Below are some examples of this behavior: The first case shows a duplicate foo
being removed. The second and third case illustrate entry reordering: the generated PATH is the same in both cases, but in the third case, the /usr/bin
entry has been moved from in-between foo
and bar
to the front of the PATH
. (This duplicate-entry removal seems to be based on just simple string-matching on the pairs of entries, as illustrated by the fourth case below where the string /usr/bin/
remains between foo/
and bar
.)
% PATH=foo:foo /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo"; export PATH;
% PATH=foo:bar /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo:bar"; export PATH;
% PATH=foo:/usr/bin:bar /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo:bar"; export PATH;
% PATH=foo/:/usr/bin/:bar /usr/libexec/path_helper
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:foo/:/usr/bin/:bar"; export PATH;
Finally, to give credit where credit is due:
While all of the command sequences above are the result of my own investigations, I was originally inspired to look into the behavior of path_helper
after reading the note here,
which pointed out that path_helper
reuses the PATH
environment variable set by the parent process.
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:
To rephrase this in pseudocode, what it's doing is:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With