Почему у меня / как я могу исправить эту ошибку: "shell_session_update: команда не найдена"

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:

• 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 the PATH variable just before control is handed to the user.
• rvm default (Also need to be the last PATH-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.