>>284
知らんけどさぁ。そのコードだけ見て判断するなら
> rbenv="$(command -v rbenv ~/.rbenv/bin/rbenv | head -1)"

まずrbenvには普通はコマンドのフルパスが入る。
二番目の~/.rbenv/bin/rbenvはわかりやすく、そこにrbenvコマンドがあればそのパス
一番目は、rbenvコマンドをPATHから検索して見つかったものが入る。だから本来はフルパス
38行目の cd "${rbenv%/*}" からもフルパスが入ってるという前提で
rbenvコマンドがある前提でそのディレクトリに移動しようとしている。

もし本当に rbenv変数に rbenv という文字列が入るとしたら
おそらく rbenvがシェル関数の場合だろう。

rbenvというシェル関数は、実は rbenv を使用していると作られる。
正確には eval "$(rbenv init -)" の実行時に定義されている。

しかし rbenv-installer は別コマンドだ、現在のシェルで定義しているシェル関数の rbenv が
呼び出したrbenv-installerという子プロセスから見つかるはずがない。

この前提が崩れるとしたら、
1. rbenv-installer を . コマンド （または source コマンド）で呼び出している。
意図的にやらない限り、そうはならないし、やってるのだから気づくだろう。

そしてもう一つ。
2. rbenvシェル関数がexport -fされている場合だ。通常exportできるのは変数だけなのだが
bashの変な機能で関数もexportできて、それを子プロセス（当然bashに限る）から参照できてしまう。
envコマンドで環境変数一覧を表示してみれば、BASH_FUNC_rbenvという特殊な名前で
rbenvシェル関数のコードが環境変数に設定されてるのが見えないか？だとしたらそれが原因だ。
普通は関数をexportしてるはずがないんだが、どこかでなにかのついで全シェル関数をexportとかやってないか？

3. もしくはBASH_ENV環境変数を使ってないか？これはbash起動時に自動的に
シェルスクリプトを実行するための変数だ、そこでrbenvシェル関数を定義していたりしないか？