我怀疑你的
.bash_profile 或
.bashrc 文件将
.rbenv/shims 添加到了你的路径中，并且在shell启动期间，在
path_helper 被调用之前运行了。
path_helper 的 man 页面开头是：
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.
关键点在于path_helper实用工具旨在向现有的PATH设置中添加内容，而不是替换它们。（实际上，它真正做的是在前面添加内容，而不是在后面添加，这对于PATH变量很重要...）
因此，如果我从我的PATH中开始一个条目，由path_helper生成的设置将确保该条目继续存在于其生成的PATH中。
% 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;
请注意，即使/etc/paths和/etc/paths.d/*的内容没有更改，foo在最后一行中被包含在我的PATH中。
同时，path_helper实用程序似乎也小心翼翼地不会产生具有重复条目的路径; 它在连接/etc/paths、/etc/paths.d/*和当前PATH之后删除重复的条目。
这后一个细节尤其令人困惑，因为它可能导致与原始PATH设置相比的条目重新排序！
以下是一些示例：第一种情况显示删除了重复的foo。 第二个和第三个案例说明了条目重新排序：生成的PATH在两种情况下都相同，但在第三种情况下，/usr/bin条目已从foo和bar之间移动到PATH的前面。(这个删除重复条目似乎只基于成对条目的简单字符串匹配，如下面第四个案例所示，其中字符串/usr/bin/仍然位于foo/和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;
最后，要归功于那些应得的人：
虽然上述所有命令序列都是我自己调查的结果，但我最初是受到阅读这里的提示而开始研究path_helper的行为，
该提示指出path_helper重用了父进程设置的PATH环境变量。
