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_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;

Answer 1

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.