I have to run a Rails (3.0.6) app locally that requires Ruby 1.9.2 (plus Mongo). I'd like to install Ruby 1.9.2 alongside my existing 1.8.7 and be able to swap between them as necessary. I prefer installing to usr/local over Macports etc. Any recommendations? I've tried installing RVM but this has proved such a pain on OS X I'd rather avoid that too.
Is there another way of running multiple Ruby versions (maybe with a prefix like this)? I only need to switch to 1.9 for this project. Or has anyone a good solution to the known OS X/RVM install issues? Specifically, on Tiger/10.4 bash doesn't support errtrace.
Update: solved with a new RVM install script: see RVM on OS X 10.4 - possible?.
RVM really is the easiest solution, and I would highly recommend you try and work that issue out first.
The only bit of advice is to make sure you configure your PATH variable to include /usr/local/bin before everything else. In your .profile or .login (depending on your shell), you should have it towards the bottom, in case there is any other lines configuring PATH as well, and then for the Bourne shell family:
export PATH="/usr/local/bin:$PATH
or for the C shell family:
set path = (/usr/local/bin $PATH)
Running ./configure alone should make it install into /usr/local, but you can explicitly state so with
./configure --prefix=/usr/local
Install Ruby from source and it will default to /usr/local/bin. Adjust your path, the #! line, or your /usr/local/bin/ruby source.rb as necessary to switch between Apple's installation of Ruby, and the one you add.
You can force a new base directory using ./configure --prefix=/... where '...' is whatever path you want. Again, once the files are installed, you can adjust the executing Ruby with one of the above methods.
Do not attempt to remove Apple's installed Ruby. It's there for their use, not for our convenience, and Apple uses it to provide some functionality. Messing with it or removing it could break things, and you probably wouldn't notice for a while.
RE: RVM, It really is the preferred way to install a user Ruby. I have it on two Macs, and a handful of different Linux boxes and the only time I had trouble was with a secured machine behind firewalls, but I can't blame RVM for those problems when it couldn't see the internet at all. And, yes, I got it working nicely, I just had to insert the manually downloaded Ruby archives into the ~/.rvm/archives directory.
If you are having problems and want to use it, it might help to temporarily strip your startup scripts, or create a temporary user, and see what happens. Additionally, the author has been very responsive and helpful the few times I've asked him questions. Contact him at:
If you still cannot find what an answer to your question, find me 'wayneeseguin' in #rvm on irc.freenode.net:
http://webchat.freenode.net/?channels=rvm
If you download the source and compile it, it should install into /usr/local by default, or you can
./configure --prefix=/usr/local
just to be sure.
Actually, compiling and installing ruby from source is an easy way to be sure you have the latest version, especially if you use git and github:
https://github.com/ruby/ruby
Related
How do I remove (all old Ruby things), reinstall (preferably one and only one Ruby version), and test my entire Ruby environment (versionmgrs, gems, however this works) on my macOS 10.14.6 system using the "Ruby-community preferred" method (some install/version manager or similar vehicle)?
I'm seeking the entire procedure, for everything Ruby-environment related: Ruby "engine," version managers, .bash_profile edits, etc.
Even though we (my team) are not Ruby developers, we're running several Ruby-based apps like Asciidoctor. As such, we're simply users and are not invested in learning all the ins-and-outs of Ruby other than just trying to get apps (like Asciidoctor) to run without problems, and that's it.
1. Remove.
I want to completely remove every little Ruby file found on the system (besides the Apple.com-based default Ruby stuff that comes with macOS--I do not to remove or even use that stuff, ever, if I can avoid it). Hombrew-based, rbenv, and rvm, and any other Ruby thing/version_manager/intstalled_directory (there seems to be lots of different procedures and no one "standard install procedure--which is all confusing to us).
So please consider all the historical Ruby-isms that might have been installed for the entire history or Ruby, because chances are I've been installing them since the very early days of Ruby, and I/we still have the same macOS image we've been carrying forward (across upgraded MacBook hardware).
And it seems to make most sense to make sure this stuff is all gone (or at least moved out of a functional path) to ensure we have a clean slate to...
2. Reinstall.
What exactly we're installing and why we're installing it is unclear. Why do we need something to manage versions of Ruby, when we only want one? Is there some reason why we need multiple versions of Ruby? And do we have to separate Ruby "things" separate from a Ruby "version manager"? Is there a "Install Ruby for non-Ruby-developer dummies" resource to help guide us through this?
(I'm not familiar with the term "version manager" to describe the actual version of interpreter/compiler software. I'm used to, as a long-standing swdev manager, managing versions of the software my teams are developing. We're guessing this may be driven by the Ruby world may not try to enforce as much cross-Ruby-version compatibility, but we only speculate. Granted, we tend to do more system programming in C/C++/Python kind of things, and less web-specific stuff like JavaScript/Ruby things. Maybe the latter has less of "I'm a developer and I do not write portable code across version platforms / I'm a programming-language/platform designer that cares less about cross-version compatibility." This is a new world for us.)
3. Testing.
When done with #2, I would like to automatically diagnose my entire Ruby environment with a comprehensive system test. Is this feasible?
If I do not do this, history tells me that I'll run into a Ruby-wonky-environment problem later. If possible, I want to get "set and forget it," for everything, all in one shot and avoid running into future problems.
Think historical things like make test (after make and make install) and brew doctor.
More details
My Ruby environment/subsystem on my macOS 10.14.6 was wonky and broken and frustrating. Said environment was result of many years (decades) of Ruby stuff/layers piled into my macOS environment (which was cloned across MacBooks over time and therefore carried forward).
I tried to rebuild it and clean it up to try and get some level of sanity. It mostly (?) seems to work, at least for running. But rvm related stuff is still failing--and do I even need rvm (it's unclear, like many things in Ruby setup for non-Ruby developers). And I still have lots of ruby-isms hanging around in .bashrc that looks unhealthy (why so many $PATH entries..?), or at least makes me uncomfortable.
I've found at least 20 different "reinstall / rebuild" references on StackExchange.com and other places, many of which offer different Homebrew-based procedures.
My gem env output. Note all these different versions associated with some ruby-like component:
3.1.2, 2.7.0, 2.7.1, 2.2.1, 2.2.0, 1.1.2
That's six different subsystem versions. In my book, that's bad.
(I'm not a Ruby developer, so pls pardon my poor Ruby "syntax.")
Apparently Ruby community members are fixated on the concept of multiple versions of Ruby installed on one OS; from a classic, old-school system-administrators perspective (that's me), multiple installed Ruby versions is something my team specifically wants to avoid. Maybe there's some need to install multiple Ruby versions on one system. Maybe it's because Ruby offers less-stable environments (features, APIs, etc) than other software systems we're used to. Regardless: without knowing more, I'd much rather manage multiple versions of Ruby with containers (like Docker).
From the perspective of this user: the Ruby world feels chaotic and unnecessarily complex. With Ruby's popularity, I'm sure there's some reason for this. My guess: Ruby values feature advancement over platform stability. This is not greatest thing when I'm wearing my sysadmin hat; it can be kind of fun when wearing my swdev hat. For this mission, I'm only wearing my sysadmin hat.
I usually use RVM when I work on Linux OSs. However, there was a time when I worked on macOS. I tried many times to install RVM on macOS but was never successful, so I tried rbenv instead. It had its differences from RVM, but it did the job for me.
It might not be the answer you're looking for, but in case it is, here are the steps to install rbenv:
Type brew install rbenv in terminal to install rbenv.
Add the command eval "$(rbenv init -)" to ~/.bash_profile to make rbenv load automatically when you open terminal.
Type source ~/.bash_profile in the terminal to apply the changes you made to the current shell session.
Type type rbenv in the terminal to verify that rbenv is setup properly. Your terminal should display the following:
rbenv is a function
rbenv ()
{
local command;
command="${1:-}";
if [ "$#" -gt 0 ]; then
shift;
fi;
case "$command" in
rehash | shell)
eval "$(rbenv "sh-$command" "$#")"
;;
*)
command rbenv "$command" "$#"
;;
esac
}
And now, to install Ruby versions:
To check for available Ruby versions for installation, type rbenv install -l in the terminal.
To install Ruby 5.5.0, type rbenv install 5.5.0 in the terminal.
To check for installed Ruby versions, type rbenv versions.
To make Ruby 5.5.0 the global Ruby version on your system, type rbenv global 5.5.0 in the terminal.
To make Ruby 5.5.0 your Ruby version in your current directory, type rbenv local 5.5.0 in the terminal.
To check your current rbenv Ruby version, type rbenv version.
And of course, type ruby -v to make sure that the setup was done correctly.
Use a Full-Fledged Ruby Version Manager
You're trying to install one or more Rubies using Homebrew, and then hoping your gem environment stays sane. Don't. Just don't.
Installing Rubies via Homebrew can exhibit weird conflicts and difficult-to-resolve error messages. You'll be much better off installing a Ruby version manager like chruby, rbenv, or RVM. Not only will this generally work better, but it will segregate your gems on a per-interpreter basis so that you can easily clean up your Ruby environment when you inevitably run into problems with gems, libraries, or Xcode upgrades.
You'll need to install Xcode and its command-line utilities. Beyond that, I'd suggest chruby and ruby-install as the simplest integration solution, but any Ruby manager will do if you set it up correctly.
(Please make sure to see the Background section at the end of this answer.)
My procedure
1. Remove all the existing Ruby stuff (except for the Ruby "system" files installed by Apple for the "core system" for macOS).
This is the part of the procedure I'm less sure of. I've asked on superuser.com about "how to remove all possible, old Ruby cruft" and will import anything learned there to this procedure. In the meantime, I found a few things Ruby-related (eg: ~/.ruby-version) for which I could not easily find any documentation/reference. It was a mini adventure. But here's what I came up with:
a) Homebrew-based stuff: brew uninstall ruby ruby-build rbenv and any other Ruby-oriented Homebrew packages. brew list | grep can be helpful to find the packages.
b) rvm uninstall -- but please first read "old file droppings" notes below, in order to retain your old rvm environment for reference.
c) Any other uninstalls (non-Apple-macOS systems installs, of course) you can find or think of, possibly including installs that result from procedures found at https://rvm.io and https://github.com/rbenv/rbenv and any other version managers you can find/think of.
2. Remove or move old Ruby file droppings from $HOME
I moved the files instead of removing them, per the following procedure. Note that the ~/.rvm move effectively does some or all of the (1b) procedure above, while retaining the old ~/.rvm environment for (possibly very-helpful) reference, eg: to rebuild your installed-gems list. Also note that you may have more or less "file droppings" in your home directory.
cd $HOME
mkdir -p .ruby-old-files/2020-04-13
mv .rbenv/ .rvm/ .gem/ .ruby-version .ruby-old-files/2020-04-13/
3. (Re)install the latest, "stable" (?) rbenv/"ruby engine" per this one-line command (this presumes Homebrew is already installed), given the rbenv version manager choice as described in the Background section below:
brew update
brew install rbenv
The above does not install the "Ruby engine" via Homebrew; rather, it install rbenv (via homebrew), which in turn installs the "Ruby engine" per the following:
rbenv install $(rbenv install -l | grep -v - | tail -1)
rbenv global $(rbenv install -l | grep -v - | tail -1)
4. Comment/delete previous ~/.bash_profile updates from past Ruby-isms
I ended up commenting out all these lines from past Ruby-driven updates, which appear to be unused by and/or conflicting with rbenv (your file may not have anything like this):
#export PATH=$PATH:~/.gem/ruby/1.8/bin:/usr/local/opt/ruby/bin
#export PATH="$PATH:$HOME/.rvm/bin" # Add RVM to PATH for scripting
#[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
# export RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl#1.1)"
5. Add this to ~/.bash_profile:
eval "$(rbenv init -)"
6. Start a new macOS Terminal.app window (or iTerm2 or similar).
7. [Optional] Re-install previous gems in new environment.
I looked at my previous .rvm bin list:
$ brew install tree
Warning: tree 1.8.0 is already installed and up-to-date
To reinstall 1.8.0, run `brew reinstall tree`
$ cd
$ tree -a .ruby-old-files/2020-04-13/.rvm/gems/ruby-2.2.1/bin/ -C | less
.ruby-old-files/2020-04-13/.rvm/gems/ruby-2.2.1/bin/
├── 3llo
├── _guard-core
├── asciidoctor
├── asciidoctor-safe
├── bundle
├── bundler
├── coderay
├── console
├── executable-hooks-uninstaller
├── github-markup
├── guard
├── imap-backup
├── listen
├── nokogiri
├── pry
├── rake
├── rdoc
├── ri
├── ruby_executable_hooks
├── setup
└── thor
0 directories, 21 files
$
(there's possibly other places to look for existing gems, as with Ruby stuff can be scattered all over the place with many "rubies" as the Ruby community calls them) and ran gem install [gem-package] for every package I wanted to reuse in my new (clean, fresh, and sane) Ruby environment. I ran some initial asciidoctor tests on my team's rather complex asciidoctor document library, and all seems initially good.
We'd prefer there be some sort of significant Ruby-engine set of "self diagnostics" (a simpler illustration: brew doctor) to give the user much more confidence that their "Ruby engine" is optimally functional. Alas, I as of yet see no such thing for Ruby.
From here moving forward I can gain more confidence in building multiple "rubies" via rbenv, and only rbenv. Before I had multiple rubies managed via multiple installers/version managers (Homebrew, rvm, and rbenv), which may have been a cause of many problems, possibly per Todd's point.
Background
Ruby has a bit of complexity and possibly runs much better with a version manager. I find this all a bit unusual, at least from my decades of swdev+sysadmin experience. I can certainly see how all these mechanisms can be very powerful. For now, I'm just trying to make my Ruby platform work.
From what I can tell, there is no "one standard way" to install and run and a standard directory to places in for Ruby on macOS. This means there's no "one standard way" to uninstall, and so one has to, if they've (often very unknowingly, like me) installed many different Ruby versions (I guess called "Rubies"?) over the years (decades?) in many different files/directories controlled by multiple different "version managers" (I guess? More on versions managers in a moment). ie, I find I have to "hunt and peck" for all the historical ways past Ruby installs/version_managers might have left file/directories placed in various areas.
Note this can happen when you have an macOS image that has lived for many years, and in my case, has been cloned across many generations of MacBooks. For someone who goes to a Ruby boot camp for a week and installs on a clean system, everything should work just peachy. For someone like me who's been an engineer/mgr for decades and possibly has all sorts of Ruby-isms laying around for his decades-old macOS image (as directed by many many different Ruby-based apps/guides on how I install stuff; not knowing that many of these procedures were effectively in conflict with each other), it can be quite the different story.
The Ruby platform apparently requires something called a Version Manager to run a Ruby platform (interpreter, compiler, engine, whatever it's called). I chose the rbenv (based upon this reference) version manager for the "install" portion of my procedure after removing/moving all the old stuff.
If it's not already obvious, it's (presumably?) best to avoid installing and running multiple version managers concurrently.
Installation options
There seems to be several ways to install the Ruby "core engine/platform" (my syntax, possibly only used by me) on macOS, with the 3-most-referenced options I've found noted below. (Note there are many other version managers to choose from not listed below.) I chose rbenv based upon this reference.
via rbenv
via rvm
via Homebrew
(1.) and (2.) above are mechanisms that can install Ruby, and these mechanisms can be installed via Homebrew. But #1 and #2 will not install Ruby via Homebrew. This can be confusing.
It appears (1.) and (2.) also enable multiple versions of Ruby to run concurrently. (3.) may not. This may be helpful due to version-to-gem/app compatibility challenges with Ruby's aggressive (?) feature movement, which sometimes comes at the expense of backwards compatibility. (I'm guessing here, but can come up with no other good explanation; community, pls comment.)
The "remove all old Ruby engines and files" approach might be extreme. My experience: Ruby's history is a mess, and over the years/decades it left all sorts of messy variances (in my home directory) lying around. It's not a big deal for me to rebuild gems by hand -- there's not that many on my system. And by keeping the pre-existing Ruby-environment files around I'm (hopefully) covered if ever I need to revert or rebuild stuff. And, for now, things feel much more "clean and sane" now that it "feels" like I've removed all the old cruft.
Even more background
My team and I are only users of Ruby-based applications, not Ruby developers, and are far from experienced in the Ruby realm. We just want to install and use and maintain applications like Asciidoctor without having to "dive in deep" on all this Ruby stuff. Everything worked okay for several years - and then all the "cruft" built up and started breaking things. When I tore it all down and properly reinstalled (above)--once I finally figured out how all the Ruby ins and outs worked--things starting working again. I believe that I, as a simple Ruby-application user, should not have to go to this level of effort just to get a Ruby app to work. In short: it should not be this hard. Hence the nature of my comments about the difficulty.
Further, I had a bad day when I first posted this question and unnecessarily aggravated several community members here that were trying hard to help--and again, my apologies, that was totally my bad--and I have since been labeled by some as the guy that "likes to complain alot." And I thoroughly deserve that label being inappropriate in a couple of my comments. Again, I apologize.
Additionally: my Ruby problems still exist whether or not folks here want to deny it or simply blame the problems on me for being mean. Regardless: I'm not disappointed with the people trying to help; I'm disappointed with the Ruby platform not supporting my overall experience well.
Please also note TamerB's helpful answer.
Of all the days I chose today to switch from rvm to rbenv. All went well far enough, there are good tutorials on this, but the fun stopped when I tried to install ruby 1.9.3.
rbenv install 1.9.3
proposed to install 1.9.3-p448 as the current version which seems ok to me, so I tried
rbenv install 1.9.3-p448
and went down from there on. It will look up something on ...cloudfront.net and then tried to fetch ruby-1.9.3-p448.tar.gz from the "usual location" which it considers to be
http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p448.tar.gz
which fails with
/usr/local/bin/ruby-build: line 144: pushd: ruby-1.9.3-p448: No such file or directory
plus a final 404-error and a host of followup error messages.
As it turns out the link above is identical to the one published on http://www.ruby-lang.org/en/downloads/ which I would consider as "official" a link as you might find for Ruby. So if you go to ruby-lang.org manually (or using the link above) you will also find a broken download (as of 2013-08-06 17:06)!
I guess this is a temporary issue and the downloads will return (2.0.0 link is also broken by the way). Not to much of a problem for me at the moment as 1.9.2 can still be installed (and I am stuck with that at my current hosting provider ...), but anyways: Are there any other options I would have to install a ruby with rbenv without these "official" distributions?
Looks like ruby-lang.org has been going on and off line for a couple of hours now.
ruby-lang status: http://www.ruby-lang.org/en/news/2013/08/06/status-issue/
GitHub Issue: https://github.com/ruby/www.ruby-lang.org/issues/259
just tested overriding the mirror for ruby-build in cap...
rbenv uses ruby-build. You can override the mirror in ruby-build url in 2 ways:
Specifying a custom ruby version (requires you to write out a config in ruby-build/share/ruby-build/my-custom-ruby
Overriding the mirror url (requires the checksum to be the same), i.e., RUBY_BUILD_MIRROR_URL= http://mirrors.ibiblio.org/ruby/2.0/ruby-2.0.0-p247.tar.gz
env RUBY_BUILD_MIRROR_URL=http://mirrors.ibiblio.org/ruby/2.0/ruby-2.0.0-p247.tar.gz ~/.rbenv/bin/rbenv install 2.0.0-p247
I had this same problem, and I was able to work around it by editing the ruby-build recipe for the particular version of Ruby I needed to download.
I installed ruby-build as an rbenv plugin, so the recipe lives here:
~/.rbenv/plugins/ruby-build/share/ruby-build
Here's the edited version of the recipe:
install_package "yaml-0.1.4" "http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz#36c852831d02cf90508c29852361d01b"
install_package "ruby-1.9.3-p448" "http://mirrors.ibiblio.org/ruby/1.9/ruby-1.9.3-p448.tar.gz#a893cff26bcf351b8975ebf2a63b1023"
#install_package "ruby-1.9.3-p448" "ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p448.tar.gz#a893cff26bcf351b8975ebf2a63b1023"
I did not try this, but you might be able to achieve a similar result by following the instructions for specifying package download mirrors.
So i'm new with this. I'm trying to install ruby on my mac with mountain lion.
im following this guide:http://www.moncefbelyamani.com/how-to-install-xcode-homebrew-git-rvm-ruby-on-mac/
when I put "brew doctor" I get this lot of warnings:
$ brew doctor
Warning: /Library/Frameworks/Mono.framework detected
This can be picked up by CMake's build system and likely cause the build to
fail. You may need to move this file out of the way to compile CMake.
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libusb-0.1.4.dylib
/usr/local/lib/libusb-1.0.0.dylib
/usr/local/lib/libusbpp-0.1.4.dylib
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .la files:
/usr/local/lib/libusb.la
/usr/local/lib/libusbpp.la
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/fuse.pc
/usr/local/lib/pkgconfig/libusb.pc
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libusb.a
/usr/local/lib/libusbpp.a
What should I do? What's happening?
I would recommend that you manage your ruby installations with either RVM or RBENV it will make your life much easier to manage different versions, upgrades, etc.
Use RVM. RVM allows you to install and manage multiple versions of Ruby on the same machine.
You can follow the instructions here to install RVM, and instructions here to install Ruby. The second link is an excellent beginners guide to get going with ruby-on-rails by the way.
Your Mac probably comes with Ruby 1.8.7. I like some of the features in 1.9.x, and they've recently released 2.0.0, so you may wish to upgrade. However there's no point doing work if you ain't gonna need it, so first decide whether you need a different version of Ruby right now. (And verify your current version with a ruby -v).
Assuming you need a new version, RVM and rbenv are two tools that make installing and managing (a.k.a. switching between) various Rubies and their versions very easy. Some people don't like RVM because it does some strange things (like override the definition of cd - change directory), but I find it simpler to use, and doesn't require you to remember to rehash every time. Read up on it and decide for yourself.
If you want to use RVM:
Install it (Google to find out how).
Make sure to source the script that it tells you to do in the output during the installation.
Start using it: rvm install <version> (e.g. rvm install 1.9.3), rvm use <version> (to switch between versions), rvm list (to see which Rubies you have installed), etc.
RVM has more online resources so it's be a good choice since you're starting. Pay attention to the error logs in your console and Google them, you'll probably see some quite accurate results (as the ruby install issues are common).
I have two related questions that I was hoping someone could help out with.
I recently installed Ruby 1.9.2 on my Mac (running Snow Leopard 10.6.4) and I haven’t been able to figure out how to get Terminal to use the new Ruby as a default, rather than the factory-installed Ruby 1.8.7. The old Ruby 1.8.7 is located in my ~/usr/bin/ruby directory while the new Ruby 1.9.2 is in ~/usr/local/bin/ruby. Someone said that I need to put the new version of Ruby's directory in the PATH prior to the old version's directory so that the system looks there first - is this correct? If so, can anyone provide step by step instructions on how to do this?
I’ve created a new directory but can’t seem to figure out the correct way to add that directory to my PATH using the Terminal bash shell. I tried using the instructions that I found here (http://www.macgasm.net/2008/04/10/ad...thin-terminal/) twice but they didn't work for me. The directory containing my program ("Ruby_Programs") shows up in the PATH but when I try to run "ruby newprogram.rb" from the command line it results in ":ruby: No such file or directory -- newprogram.rb (LoadError)". The file definitely exists and is a functional Ruby program. I did change the name of the directory to "Ruby Programs" and then back to "Ruby_Programs" - could that have somehow caused this problem?
Any help would be greatly appreciated. Here is my current PATH:
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/sbrriffe/src:/usr/X11/bin:/Users/sbriffe/Ruby_Programs/:
You might want to check out rvm. You can install multiple versions of ruby side by side and easily switch between them. If you follow the rvm installation notes you won't have any more path problems.
Your Ruby Programs directory shouldn't be in your path: the location of your ruby interpreter should be. Then, you cd to the location of your ruby program, and run it from there: ruby program.rb.
Since you are on a Mac, check out homebrew for something that will make installing software easier. I have my homebrew set up in /usr/local, and it works great.
Once you have installed stuff where you need it, then you'll want to adjust your $PATH. The items in $PATH are searched in the order they appear, so in your ~/.bashrc, you'll want to add:
export PATH=/usr/local/bin:$PATH
To make sure /usr/local/bin gets searched before /usr/bin.
I would use RVM to get everything installed, and then once you have RVM installed it is easy to set your default Ruby version.
Check out https://rvm.io/ -- once you have that installed you can change your default by using : $ rvm use 1.9.2 --default
hope that helps- you can do this with any version, not only 1.9.2
I'm trying to install some Ruby Gems so I can use Ruby to notify me when I get twitter messages. However, after doing a gem update --system, I now get a zlib error every time I try and do a gem install of anything. below is the console output I get when trying to install ruby gems. (along with the output from gem environment).
C:\data\ruby>gem install twitter
ERROR: While executing gem ... (Zlib::BufError)
buffer error
C:\data\ruby>gem update --system
Updating RubyGems
ERROR: While executing gem ... (Zlib::BufError)
buffer error
C:\data\ruby>gem environment
RubyGems Environment:
- RUBYGEMS VERSION: 1.2.0
- RUBY VERSION: 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
- INSTALLATION DIRECTORY: c:/ruby/lib/ruby/gems/1.8
- RUBY EXECUTABLE: c:/ruby/bin/ruby.exe
- EXECUTABLE DIRECTORY: c:/ruby/bin
- RUBYGEMS PLATFORMS:
- ruby
- x86-mswin32-60
- GEM PATHS:
- c:/ruby/lib/ruby/gems/1.8
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- http://gems.rubyforge.org/
Found it! I had the same problem on windows (it appeared suddenly without me doing an update, but whatever):
It has something to do with multiple conflicting zlib versions (I think).
In ruby/lib/ruby/1.8/i386-msvcrt, make sure that there exists a zlib.so file. In my case, it was already there. If not, you may try to install ruby-zlib.
Then go to ruby/lib/ruby/site_ruby/1.8./i386-msvcrt and delete the zlib.so file there.
In ruby/bin, there should be a zlib1.dll. For some reason my Ruby version did not use this dll. I downloaded the most recent version (1.2.3) and installed it there. I had to rename it to zlib.dll for it to be used.
And tada! Rubygems worked again.
Hope this helps.
Firstly, I thank the person, who came up with the solution to the missing zlib problem. (It wasn't me. :-)
Unfortunately I lost the link to the original posting, but the essence of the solution on Linux is to compile the Ruby while zlib header files are available to the Ruby configure script. On Debian it means that zlib development packages have to be installed before one starts to compile the Ruby.
The rest of my text here does not contain anything new and it is encouraged to omit it, if You feel comfortable at customizing Your execution environment at UNIX-like operating systems. The following is a combination of a brief intro to some basics and step by step instructions.
------The-start-of-the-HOW-TO-------------------------
If one wants to execute a program, let's say, irb, from a console, then the file named irb is searched from folders in an order that is described by an environment variable called PATH. It's possible to see the value of the PATH by typing to a bash shell (and pressing Enter key):
echo $PATH
For example, if there are 2 versions of irb in the system, one installed by the "official" package management system, let's say, yum or apt-get, to /usr/bin/irb and the other one that is compiled by the user named scoobydoo and resides in /home/scoobydoo/ourcompiledruby/bin then the question arises, which one of the two irb-s gets executed.
If one writes to the
/home/scoobydoo/.bashrc
a line like:
export PATH="/home/scoobydoo/ourcompiledruby/bin:/usr/bin"
and restarts the bash shell by closing the terminal window and opening a new one, then by typing irb to the console, the
/home/scoobydoo/ourcompiledruby/bin/irb gets executed. If one wrote
export PATH="/usr/bin:/home/scoobydoo/ourcompiledruby/bin"
to the
/home/scoobydoo/.bashrc
,then the /usr/bin/irb would get executed.
In practice one wants to write
export PATH="/home/scoobydoo/ourcompiledruby/bin:$PATH"
because this prepends all of the values that the PATH had prior to this assignment to the /home/scoobydoo/ourcompiledruby/bin. Otherwise there will be problems, because not all common tools reside in the /usr/bin and one probably wants to have multiple custom-built applications in use.
The same logic applies to libraries, except that the name of the environment variable is LD_LIBRARY_PATH
The use of the LD_LIBRARY_PATH and PATH allow ordinary users, who do not have root access or who want to experiment with not-that-trusted software, to build them and use them without needing any root privileges.
The rest of this mini-how-to assumes that we'll be building our own version of ruby and use our own version of it almost regardless of what is installed on the system by the distribution's official package management software.
1)=============================
First, one creates a few folders and set the environment variables, so that the folders are "useful".
mkdir /home/scoobydoo/ourcompiledruby
mkdir -p /home/scoobydoo/lib/our_gems
One adds the following 2 lines to the
/home/scoobydoo/.bashrc
export PATH="/home/scoobydoo/ourcompiledruby/bin:$PATH"
export GEM_HOME="/home/scoobydoo/lib/our_gems"
Restart the bash shell by closing the current terminal window and opening a new one or by typing
bash
on the command line of the currently open window.
The changes to the /home/scoobydoo/.bashrc do not have any effect on terminal windows/sessions that were started prior to the saving of the modified version of the /home/scoobydoo/.bashrc
The idea is that the /home/scoobydoo/.bashrc is executed automatically at the start of a session, even if one logs on over ssh.
2)=============================
Now one makes sure that the zlib development packages are available on the system. As of April 2011 I haven't sorted the details of it out, but
apt-get install zlibc zlib1g-dev zlib1g
seems to be sufficient on a Debian system. The idea is that both, the library file and header files, are available in the system's "official" search path. Usually apt-get and alike place the header files to the /usr/include and library files to the /usr/lib
3)=============================
Download and unpack the source tar.gz from the http://www.ruby-lang.org
./configure --prefix=/home/scoobydoo/ourcompiledruby
make
make install
4)=============================
If a console command like
which ruby
prints to the console
/home/scoobydoo/ourcompiledruby/bin/ruby
then the newly compiled version is the one that gets executed on the command
ruby --help
5)=============================
The rest of the programs, gem, irb, etc., can be properly executed by using commands like:
ruby `which gem` install rake
ruby `which irb`
It shouldn't be like that but as of April 2011 I haven't figured out any more elegant ways of doing it. If the
ruby `which gem` install rake
gives the zlib missing error again, then one should just try to figure out, how to make the zlib include files and library available to the Ruby configure script and recompile. (Sorry, currently I don't have a better solution to offer.)
May be a dirty solution might be to add the following lines to the
/home/scoobydoo/.bashrc
alias gem="`which ruby` `which gem` "
alias irb="`which ruby` `which irb` "
Actually, I usually use
alias irb="`which ruby` -KU "
but the gem should be executed without giving the ruby the "-KU" args, because otherwise there will be errors.
------The-end-of-the-HOW-TO------------------------
I just started getting this tonight as well. Googling turned up a bunch of suggestions that didn't deliver results
gem update --system
and some paste in code from jamis that is supposed to replace a function in package.rb but the original it is supposed to replace is nowhere to be found.
Reinstalling rubygems didn't help. I'm reinstalling ruby right now.........and it is fixed. Pain though.
How about cd into rubysrc/ext/zlib, then ruby extendconf.rb, then make, make install.
After do that, reinstall ruby.
I did this on ubuntu 10.04 and was successful.
A reinstall of Ruby sorted this issue out. It's not what I wanted; I wanted to know why I was getting the issue, but it's all sorted out.
It most often shows up when your download failed -- i.e. you have a corrupt gem, due to network timeout, faulty manual download, or whatever. Just try again, or download gems manually and point gem at the files.
if gem update --system not works and rename ruby/bin/zlib1.dll to zlib.dll not helps try:
Open file RUBY_DIR\lib\ruby\site_ruby\1.8\rubygems.rb
And replace existed def self.gunzip(data) by this:
def self.gunzip(data)
require 'stringio'
require 'zlib'
data = StringIO.new data
# Zlib::GzipReader.new(data).read
data.read(10) # skip the gzip header
zis = Zlib::Inflate.new(-Zlib::MAX_WBITS)
is = StringIO.new(zis.inflate(data.read))
end
Try updating ZLib before you do anything else. I had a similar problem on OS X and updating Compress::Zlib (a Perl interface to ZLib) cured it - so I think an old version of ZLib (is now 1.2.3) may be where your problem lies...
install pure ruby zlib if all else fails