

On rvm's *cd* script - benatkin
http://batkin.tumblr.com/post/8847990062/on-rvms-cd-script

======
pilif
> I knew about .rvmrc’s behavior, but I thought that the shell must have
> provided a hook for the directory changing!

And this, my friends, is another reason to use zsh which calls chpwd()
whenever the working directory has changed, which is in fact precisely what
the infamous rvm cd script does (I wasn't sure, but just checked).

So those people already running zsh with rvm, you are free of the cd
replacement.

Aside of that I still believe that rvm might be a tad bit intrusive and as a
Linux user of old, I learned to value the use of distribution packages. But
rvm is so darned convenient... :-)

~~~
IdeaHamster
Thank you for doing the digging for me! I've been hearing all this controversy
about overriding 'cd', but when I open a shell (with RVM installed), I still
see the following:

    
    
        ~/Desktop > which cd
        cd: shell built-in command

------
spacemanaki
"Finally, one thing I’d like to know, is if rvm was loaded, would another
script be able to override cd in the same way that rvm does, and would both
script’s hooks be called?. I suspect that the answer is yes."

I'm not a shell expert but I played around with the code in this SO answer
from Wayne Sequin and I think the last script to be loaded would win, in other
words another script might break RVM. At least that's what appeared to be
happening in Bash 3.2 on OS X.

[http://stackoverflow.com/questions/5605277/how-does-rvm-
dete...](http://stackoverflow.com/questions/5605277/how-does-rvm-detect-when-
youve-changed-directories)

btw I use RVM and find it pretty useful.

~~~
sstephenson
Which is exactly why it's a terrible idea. There is no "super" mechanism in
Bash. Imagine if the Perl, Python and Node equivalents of rvm overrode cd --
they'd all have to be aware of each other's existence in order to play
together nicely.

Overriding cd for dependency injection purposes is like killing a fly with a
machine gun. It's completely inappropriate for the task at hand, and it's
precisely the kind of problem that $PATH is designed to solve.

Furthermore, rvm breaks the expected behavior of the cd command by prompting
you with security theatrics the first time you enter a project with an .rvmrc
file: <https://gist.github.com/34c251a56e83c61c667e> This kind of thing wreaks
havoc with third-party programs that attempt to interface with rvm. I've had
to deal with far too many bug reports in Pow as a result of this messy
behavior.

This is not some theoretical concern. It's just bad design.

~~~
zmanji
How would you get the same behavior of project base .rvmrc files without
hijacking cd?

~~~
sstephenson
By using a shim approach, like rbenv.

1\. Maintain a directory of shim binaries with the same name as every Ruby
binary (ruby, irb, rake, gem, etc).

2\. Put the shim directory at the front of your $PATH.

3\. When a shim is run (as in typing `rake` from the command line or running a
script with a `#!/usr/bin/env ruby` shebang), check for a version file in the
current directory or any parent directory, map that to the right path, and re-
exec the corresponding binary.

~~~
zmanji
Doesn't this solution not scale? Doesn't this mean a shim must be created for
every gem that I install that has a binary? Or is this only required for
"core" binaries?

~~~
sstephenson
`ls -l /usr/bin | wc -l` reports 1085 entries on my machine. Meanwhile, I have
40 entries in my ~/.rbenv/shims directory. I think the shell can handle it.

~~~
zmanji
I'm sorry, I was not aware of the 'rehash' function, I thought rbenv would
have to ship with all the required shims. The rehash functionality is quite
clever and cool. Is there an easy way to have that automatically execute after
I do any installation of a ruby or gem?

------
termie
What a shame. Overriding a shell built-in is a fucking horrible idea. While it
might be technically innocuous -- and I'm sure for most people it is --
philosophically and politically this is a design failure that will taint RVM
forever. It makes people wonder what other poor design choices lurk beneath.
People are mostly too lazy to look at this objectively and RVM will suffer for
it. What a shame.

------
telemachos
> Only one of a dozen or so posts I’ve read about raising concern with it
> cited a concrete problem with it. It was also for an earlier version of rvm,
> and it may already be fixed.

The exit status issue is definitely fixed[1]. I had the problem, traced it
back to rvm, popped into #rvm on irc, and it was fixed in two seconds. Wayne
is exceedingly active there (and mpapis also now). Things tend to get fixed
very fast.

(For the record, the other issue I had - TAB autocompletion with cd - is also
fixed, though that one was more complicated. As I recall, Wayne was getting
complaints from both directions. Some people reported that autocompletion for
_cd_ wasn't happening with rvm, and so Wayne added custom autocompletion for
_cd_ [2]. Then I and some others began to complain that our previously working
_cd_ autocompletion from _CDPATH_ and/or _bash-completion_ wasn't working. It
took a couple of weeks to sort out, but now rvm's autocompletion is opt-in[3].
If you don't ask for it, you don't get it.)

[1]
[https://github.com/wayneeseguin/rvm/commit/f9aa3adebcca54792...](https://github.com/wayneeseguin/rvm/commit/f9aa3adebcca547924c8095fa7696967bd2d8d15)

[2]
[https://github.com/wayneeseguin/rvm/commit/c683a7c069bf8ca30...](https://github.com/wayneeseguin/rvm/commit/c683a7c069bf8ca3054cea94d25dcbb034db8d90)

[3]
[https://github.com/wayneeseguin/rvm/commit/f856e3c8f50168776...](https://github.com/wayneeseguin/rvm/commit/f856e3c8f50168776d7dd8edd7edc052c9402591)

