rbenv spins out of control if neiter greadlink nor readlink is available

[jf647]

I'm familiar with the patch to use greadlink on Solaris instead of readlink:

#43

The problem I have is that greadlink doesn't appear to be a standard Solaris utility, and rbenv behaves very poorly when neither readlink nor greadlink is available.

This is a gist of 'rbenv versions' on Linux:

https://gist.github.com/jf647/f39ff6cab054d6b6f52a

And this is the same command on Solaris without readlink or greadlink installed.

https://gist.github.com/jf647/c28f8b35fcfba8c94952

As you can see, when it attempts to use greadlink or readlink, it comes back with the bare command rather than something qualified. That gets re-execed, and we loop forever.

I'm not sure where the author of the original pull request found greadlink. Possibly it came from OpenCSW's coreutils:

http://www.opencsw.org/search/coreutils/

Which installs greadlink in /opt/csw/bin, but it certainly won't be available on a stock system. coreutils is also available from www.sunfreeware.com, though the maintainer of that site is switching to a freemium model. While coreutils is available for free (with registration) right now, there's no guarantee it will continue to be so.

The fix is either to clearly document the requirement (especially as not having it installed can take down a production server in minutes by using up all available memory) or improve rbenv so that in the absence of readlink or greadlink rbenv quits with an error.

[sstephenson]

Thanks for the report. I agree we should fail fast with an error if neither readlink nor greadlink is available. Would you like to work on a patch?

[jf647]

I'll take a whack at it. Hopefully I'll have a pull req up by end of day.

[sstephenson]

Thank you!

[jf647]

I decided to set up a preflight check function rather than just enhance resolve_link. Because resolve_link is used in expansion, exiting from it in case of failure doesn't stop the main script.

precheck() may prove useful for other similar situations in the future.

[mislav]

Thanks for reporting this. Closing in favor of your pull request #390

BTW you can use http://defunkt.io/hub to transform your issues to pull-requests from the command-line