Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Tools
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

Removing Old Ruby Source Installation After a Leopard Upgrade

Chad Woolley
Friday, February 22, 2008


Removing Ruby

I just upgraded to Leopard on my Mac. Previously, on Tiger, I had installed Ruby from source, in the default /usr/local/lib prefix. After reading the discussion on the Apple-provided Ruby installation, I decided to try it – mainly to ensure that my apps, such as GemInstaller, play well with it (on Pivotal’s Mac pair workstations, we still install Ruby from source, so everything matches our demo/production environments as closely as possible, and things are in consistent locations).

So, I wanted to uninstall the old Ruby source installation, and only have the Apple-provided Ruby on disk. Googling for a few minutes did not provide exact instructions for this, so I’m writing up what I did, in hopes that it will help you!

I didn’t use the “–prefix” option when I originally installed Ruby from source, so it was in the default location of /usr/local/lib/ruby, with binaries in /usr/local/bin.

WARNING: Use ‘rm -rf’ at your own risk – a sleep-deprived encounter with ‘rm -rf’ and a stray file named ‘~’ is what “motivated” my Leopard upgrade in the first place…

First, I deleted the old ruby libraries/gems, which was easy enough, because they all lived under /usr/local/bin/ruby:

sudo rm -rf /usr/local/lib/ruby

However, this left all the old ruby/gems executables in /usr/local/bin. This resulted in errors when trying to run executable gems that I had not yet installed under the Apple Ruby installation:

$ cheat
/usr/local/bin/cheat:9:in `require': no such file to load -- rubygems (LoadError)
from /usr/local/bin/cheat:9

Instead of a cryptic rubygems error, I should get a ‘file not found error’:

$ sudo rm /usr/local/bin/cheat
$ cheat
-bash: /usr/local/bin/cheat: No such file or directory

So, I want to purge everything ruby-releated from my /usr/local/bin folder. I whipped up a quick ruby one-liner which just prints out (almost) all ruby-related files in /usr/local/bin:

ruby -e "old_ruby_execs = `egrep 'rubygems|bin/ruby|env ruby' /usr/local/bin/*`; require 'pp'; pp old_ruby_execs.split("n").collect{|line| line.split(':').first}.uniq"

Yeah, I know, ugly and obtuse, but one-liners are kind of fun, and help me remember that Ruby is great tool for sysadmin scripts. Feel free to put it in a class and test it if you are so inclined.

Even though I tried to make a fairly specific regexp for egrep, when inspecting that list, I did find a ‘jgem’ file, which was part of JRuby. I’m planning on reinstalling JRuby anyway, so I didn’t care if that got deleted along with the other ruby stuff.

Anyway, if the output of that looks like everything you want to delete, then run this one-liner to do the actual deed (the ‘sudo echo’ is to ‘prime’ the sudo auth, so you don’t get a noninteractive password prompt):

sudo echo; ruby -e "old_ruby_execs = `egrep 'rubygems|bin/ruby|env ruby' /usr/local/bin/*`; old_ruby_execs.split("n").collect{|line| line.split(':').first}.uniq.each { |exec| p 'removing ' + exec; `sudo rm #{exec}`}"

After that, the only thing that I saw left was the ‘ruby’ executable itself, which I whacked as well:

$ sudo rm /usr/local/bin/ruby

That seems to be about it, as least good enough to get all the old invalid executables off my path. I’m sure this could have been done cleaner if I had taken more care with the original source install. However, a good brute-force approach never hurt anyone. Much. Feel free to post links to relevant and helpful stuff.

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

6 Comments

  1. Paul Paradise says:

    It won’t help you if you already have a /usr/local/bin that’s scattered full of stuff, but if you’re starting from a clean slate give [GNU Stow](http://www.gnu.org/software/stow/) a try.

    Basically, you install everything with –prefix=/usr/local/stow/somepackage-1.2.3, then just run stow from /usr/local. It walks through the contents of /usr/local/stow/*/{bin,lib,etc} and creates symlinks as appropriate to create the real /usr/local/{bin,lib,etc}. Uninstalling an app is as easy as deleting its directory from /usr/local/stow and re-running stow.

    February 22, 2008 at 10:00 pm

  2. bryanl says:

    This is why I try to stick with macports for just about everything.

    February 23, 2008 at 10:52 pm

  3. Ajit says:

    I would kill to upgrade my mac to leopard now. But im still saving up for it. This post makes me even more excited to do so! Sems more on ruby i could tinker around with.

    February 24, 2008 at 1:57 pm

  4. Chad Woolley says:

    Thanks for the comments!

    @Paul – Thanks for the link to Stow. That looks interesting. However, in a dynamic environment with many diverse projects, developers, customers, and production environments, it is a challenge to get everyone to agree on a standard for software installation, much less follow it. “Install ruby from source” is a simple, repeatable, cross-platform standard (as long you don’t consider Windows a platform). Using specific prefixes and special methods of installation are a great practice when you have complete control and ownership over your systems. In other situations, “configure/make/make install” are as standard as you are going to get :)

    @bryanl – Yes, I probably would have tried macports for this, but I want to try out the bundled Leopard Ruby, just to see firsthand what problems, if any, I encounter.

    @ajit – I’m not a rabid mac fan (this macbook is the first mac I’ve owned, and I like it a lot). I have to say though, Spaces and native tabbed terminal are a LOT nicer than VirtueDesktop and iTerm on Tiger, which caused me continual hassles. Those were the only features I really cared much about :) Time Machine looks pretty cool too…

    – Chad

    February 24, 2008 at 7:15 pm

  5. Wincent Colaiuta says:

    I don’t think I’d use Ruby for that one-liner. This is exactly the kind of task the shell was built for:

    cd /usr/bin # (or wherever)
    egrep ‘gems|ruby’ * | awk -F ‘:’ ‘{print $1}’ | uniq

    February 25, 2008 at 10:42 am

  6. Chad Woolley says:

    @Wincent,

    Yep, you can definitely use shell, or perl, or python, or whatever works for you. The point is – have a scripting language in your toolkit to whip out quick one-liners for tasks that would take forever to do manually.

    Also, still be careful with regexes – especially when you use them to delete files. There might be some executables with ‘ruby’ or ‘gems’ in them that you still want to keep around :)

    February 26, 2008 at 4:34 am

Add New Comment Cancel reply

Your email address will not be published.

Chad Woolley

Chad Woolley
Denver

Recent Posts

  • Automating Bundler In Your Deploy
  • [ANN] GemInstaller 0.5.3 Released
  • The Great Ruby IDE Smackdown of '09
Subscribe to Chad's Feed

Author Topics

bundler (1)
geminstaller (2)
open source (5)
rubygems (4)
ide (1)
ruby on rails (5)
gogaruco (19)
government (1)
agile (18)
pivotaltracker (1)
testing (2)
mac (2)
remote (1)
rant (1)
mtnwestrubyconf (1)
dependency injection (1)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Tools
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >