/usr/libexec/path_helper vs. ~/.bash_profile

/usr/libexec/path_helper ends up wrecking local path customizations you might have intended in ~/.bash_profile. Regardless of the path order specified in your ~/.bash_profile, /usr/libexec/path_helper puts its paths in-front.

This actually isn't a problem unless you end up using a nested shell. For example, in my Terminal.app, I like to use a configuration that runs the command tmux attach || tmux new with the checkbox checked for "Run inside shell". The effect of this is that Terminal.app creates the initial shell, causing my .bash_profile to run. Then, it runs the configured command (tmux). tmux spawns its own bash sub-shell, but before the .bash_profile gets run in this sub-shell, path_helper has already rewritten the PATH from where the (outer shell's) .bash_profile had left it. All the same paths are there, but now there're reordered such that /etc/paths and /etc/paths.d paths are in front. That kindof wrecks my intent as expressed in my .bash_profile:

function insert_in_path() {
  [[ "${PATH}" =~ "${1}" ]] || export PATH="${1}:${PATH}"
}

insert_in_path "~/.gem/ruby/1.8/bin"
insert_in_path "~/.virtualenv/bin"
insert_in_path "$(/usr/local/bin/npm -g bin)"
insert_in_path "$(/usr/local/bin/npm bin)"

The point was to have a few developer-specific paths up-front, but in the bash sub-shell, they're last. Thanks a lot, Apple! Next trial: see whether setting homebrew's /usr/local/bin/bash as my shell avoids the problem with path_helper. Wish me luck...