TL;DR: Make sure RVM is up-to-date to at least 1.26.11 by re-installing or issuing the command rvm get head, and is only being initialized once per terminal environment.
Result
Eventually I was able to fix my environment. I will post some information pertaining to my specific problem in an effort to help some, even though others may have the same symptom but another root cause.
Cause
One part of the root problem was coming from RVM, and how it was being initialized for my command line environments. I had found a couple different ways to do this, especially since one extra method was specifically crafted for the fish shell environment.
It seems the root cause was either:
- initializing RVM more than once, because I had multiple statements, one per terminal configuration file, and because of how they were chained, I was not aware of the others that were automatically added.
- Or, somehow statements were added that mixed the initialization for one terminal environment, say
fish, and were being run in my other terminal environment, bash, or vice versa. This can be seen in my details below where the broken bash PATH has some of the paths delimited by :s, but then others also included by spaces, which is incorrect syntax for bash, but correct for fish.
- Or both were happening!
Then the other part of the root problem was that there seems that an RVM/direnv related bug crept up recently regarding the trap function. I probably encountered this again by having one of the other problematic releases of RVM that could be caused by:
- A re-installation:
curl -sSL https://get.rvm.io | bash
- A manual update:
rvm get head
- An automatic update (that I had just done) by adding
rvm_autoupdate_flag=2 to ~/.rvmrc
This problem should be fixed as of March 30th, 2016, or release 1.26.11:
The Story
After fighting with the GNU utilities to do a complete search of the file system, peeking inside file contents, I used Atom to do this to more success, and found that the only occurrence of shell_session_update was found in the /etc/bashrc_Apple_Terminal file mentioned by Zanchey (besides history files and such). I'm also not sure why that was being run because I was using iTerm(2), and the value of $TERM_PROGRAM in that case is iTerm.app and not Apple_Terminal.
It also didn't help that I, for some reason, had to manage the RVM installation more than once, going through the installation process, which apparently adds configuration to several 'dotfiles' already, where I had also manually added some or the lines.
Along with that I had made a .bashrc file and linked to it from .bash_profile on my Mac, since it apparently did not exist by default. I had previously read on a Linux system that, by convention, .bash_profile is good for some customizations, and .bashrc is good for others such as defining user aliases and functions, or vice versa. So I was not accustomed to looking inside the .bash_profile file, and especially not the .profile file, all in the user directory, which similar system copies as well. Let's also not forget a path_helper is in the mix(!), but did not seem to contribute to any problems.
The possible ways to set-up the environment, that may be correct or not, are as follows:
More Details
For more incredible verbosity, here are some example paths I captured between by different environments while debugging the problem:
Original (broken) fish PATH
/Users/username/.rvm/gems/ruby-2.0.0-p648/bin /Users/username/.rvm/gems/ruby-2.0.0-p648@global/bin /Users/username/.rvm/rubies/ruby-2.0.0-p648/bin /Users/username/.rvm/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /usr/local/munki /Users/username/.rvm/bin
'Naturally' better fish PATH
/usr/local/opt/coreutils/libexec/gnubin /usr/local/opt/findutils/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /usr/local/munki
Original (broken) bash PATH
/libexec/gnubin:/bin:/Users/username/.rvm/gems/ruby-2.0.0-p648/bin /Users/username/.rvm/gems/ruby-2.0.0-p648@global/bin /Users/username/.rvm/rubies/ruby-2.0.0-p648/bin /Users/username/.rvm/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /usr/local/munki:/Users/username/.rvm/bin
'Manually' Fixed bash PATH
/libexec/gnubin:/bin:/Users/username/.rvm/gems/ruby-2.0.0-p648/bin:/Users/username/.rvm/gems/ruby-2.0.0-p648@global/bin:/Users/username/.rvm/rubies/ruby-2.0.0-p648/bin:/Users/username/.rvm/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/munki:/Users/username/.rvm/bin:/Users/username/.rvm/bin
'Naturally' better bash PATH
/usr/local/opt/coreutils/libexec/gnubin:/usr/local/opt/findutils/bin:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/opt/findutils/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/munki
Notes:
- The 'original's were from starting the brand new environment in either command line interpreter while having the problem.
- The 'manual' is of course when I took the incorrect path string, fixed the syntax errors, and saw more proper operation of the interpreter, so I knew what to expect when continuing to fix the root cause.
- The 'natural's were from when I first skipped loading my terminal environment configuration files such as
.bashrc and so on, and then eventually had them run after the problem was solved.
shell_session_updateis a Bash function installed by OS X in/etc/bashrc_Apple_Terminal, so presumably something in the Bash commands that RVM runs is producing it as output.