# Why am I having / how can I fix this error: “shell_session_update: command not found”

## Background

I am getting into Ruby 2.x, and Rails 4.x, on a MacBook using OS X El Capitan (10.11.3), using the fish shell, employing the integration listed on this page: RVM - Fish Shell (Integration)

## Problem

When executing various commands such as rvm version, rvm install ..., rvm use ..., rvm --default ..., etc., I receive the following error message:

/var/folders/2w/zhgybz7d25s1gdy41qdxwp48001gfh/T/rvm.fish.Pqd0CuZRJW: shell_session_update: command not found


Quick Google searching does not return any related results that would help me identify and/or fix the problem, as has worked for many of my other development set-up issues.

I did a quick text search in the rvm.fish functions file, under the .config/fish directory, and also inside the $HOME/.rvm/bin/rvm main executable, and did not see a command such as shell_session_update being called directly in that file. ## Question Does anyone know why this is happening, and how I can fix it? I am a person that likes to fix the things in front of me, so that only the things I need to take action on appear in front of me, so I would like to remove this error/warning message. :) P.S. A particular Ruby version (2.0.0) that I was attempting to install and use, does seem to be functioning appropriately, even in the same terminal (iTerm(2)) session, without having to restart it. I have since closed that one and have created a new terminal session, and still see the message appear when running the various aforementioned commands. • shell_session_update is 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. – Zanchey Feb 23 '16 at 14:02 ## 2 Answers 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

'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

'Manually' Fixed bash PATH

'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.
• rvm get head and then rvm reinstall {version} for each version ended up fixing for me – TomFuertes May 6 '16 at 20:18
• If using the curl install method: curl -sSL https://get.rvm.io | bash -s head --ruby – rynop Jun 1 '16 at 15:15
• This answer is gold. Useful and thorough. – TehShrike Aug 19 '16 at 23:46
• I had this "problem" after installing bash-git-prompt. Reinstalling rvm seemed like naaah too much. So I just moved <rvm sourcing line> to the end in my .bash_profile. Fixed. – A.D. Sep 6 '16 at 5:20
• I've usually found that fixed this other error message referenced here: stackoverflow.com/questions/18276701/… “Warning! PATH is not properly set up” Maybe you had sourcing lines somewhere else that would make it more similar to this issue? That wouldn't exactly make sense, but anything's possible. – Pysis Sep 6 '16 at 14:06

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.