Why am I having / how can I fix this error: "shell_session_update: command not found"
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 brokenbash
PATH has some of the paths delimited by:
s, but then others also included by spaces, which is incorrect syntax forbash
, but correct forfish
. - 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:
- GitHub - direnv/direnv - Issue: /bin/bash: shell_session_update: command not found #210
- GitHub - rvm/rvm - Issue: RVM overwrites bash exit trap defined in OS X El Capitan #3540
- GitHub - rvm/rvm - Issue: OSX (El Capitan) rvm source in .bash_profile ruins .bash_history writing (Terminal.app) #3560
- GitHub - rvm/rvm - Pull Request: Bug with bash sessions on OSX 10.11+ #3627
- GitHub - rvm/rvm - Issue: should deal with ~/.bash_sessions_disable #3628
- GitHub - rvm/rvm - Issue: Fish shell error after stable update #3655
- GitHub - rvm/rvm - Issue: Don't trap with a non-existent command #3657
- GitHub - rvm/rvm - Release: Comparing changes 1.26.11..master
- cleanup restoration of shell_session_update hook on EXIT, update #3657,update #3628
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:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
export PATH="$PATH:$HOME/.rvm/bin"
(as the last line that modifies thePATH
variable just before control is handed to the user.rvm default
(Also need to be the lastPATH
-modifying line. From: StackOverflow - Getting “Warning! PATH is not properly set up” when doing rvm use 2.0.0 --default)
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.
I too had the same problem. Later I found that there is already an issue present in rvm repo for this. And they have fixed it in one of the pull requests.
To fix this either upgrade the rvm to the latest version or point it to the current development revision.
rvm get head
For more details refer to this post.