On rvm's cd script

http://batkin.tumblr.com/post/8847990062/on-rvms-cd-script

by benatkin • 15 years ago

54 16 15 years ago

batkin.tumblr.com

"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...

btw I use RVM and find it pretty useful.

sstephenson3• 15 years ago

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.

zmanji3• 15 years ago

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

benatkin2• 15 years ago

> 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.

That would be a problem until rvm fixed it. Then its users would have to update it. It's not ideal, I know, but rvm is very much an active solution. Because it's used to install rubies, which get updated, its users update it.

That's one great thing about rbenv: it's easier to write, and thus easier to write clones. I'm looking forward to seeing a node.js developer adopting your shim approach. By the way, I'm glad they're plain sh scripts, so I can still use Xavier Shay's technique for making no-dependency ruby scripts fast. The rubygems wrapper scripts run a lot of code and don't provide a convenient option to skip it if it's not needed. By the way it would be cool if, with a plugin of sorts, reshim could remove require 'rubygems'. It could get people running more than one ruby CLI tool at a time (with pipes and/or backquotes) more often by shaving off the approximately half-second rubygems load time.

https://github.com/xaviershay/xtdo

> 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.

I like your shim approach but while it may be obvious to you, I found it quite clever. I think virtualenvwrapper could use it. I don't think it was like killing a fly until you introduced this idea, which most of us hadn't heard of or considered.

> 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.

You were using it in a different way than most, up until you wrote pow, and found a weak point. The trust database should have a way to inspect it, and it should have been documented. It's frustrating, I know.

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

I don't think the rvm, virtualenv, or virtualenvwrapper developers particularly liked designing (or attempting to design) this part of their system. If they could have skipped out on this feature and still have the benefit, I think they would have. I'm glad you found a path that you enjoyed taking to solve this problem.

By the way I'm a happy pow user and I'm glad you wrote rbenv since it makes pow easier for you to support and maintain. I hope it helps me to use my rvm-installed rubies with pow.

scrrr• 15 years ago

(in bash, OSX) if I type

  $ type cd
    cd is a function
    cd () 
    { 
      builtin cd "$@";
      local result=$?;
      __rvm_project_rvmrc;
      __rvm_after_cd;
      return $result
    }

I don't really understand what happens, but the "builtin" looks like some sort of "super", e.g. call original cd, which would allow to chain multiple overrides, no?

benatkin2• 15 years ago

Oh, I missed the builtin part of it. /slaps forehead

pilif3• 15 years ago

> 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• 15 years ago

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

telemachos• 15 years ago

> 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...

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

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

termie• 15 years ago

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.

On rvm's *cd* script

Related Stories

On rvm's cd script