ruby instabilities

Mon, Dec 15, 2008

I’ve got loads of images on Flickr and I thought it would be a good idea to write a small desktop app that uses the Flickr API to download them and preserve the collections and sets hierarchy at the same time. I could then back them up to DVD. The question was, what language to use? I’ve been playing around with Ruby, mostly text processing and file handling, so I thought I’d get deeper into it and write the app in it. Big mistake!

I’d previously noticed a very strange phenomenon I’d never seen before but didn’t really think much of it at the time but since what I’m doing at the moment actually crashes the OS X Finder, I thought I’d better bring it up. When I was writing the Siva stats application, I used Ruby to create the final directory that held all the stats and as debugging in Ruby is a nightmare mess of puts, I created a development “snapshot” by copying the current state of the dir to a backup. Then I noticed Ruby’s find file functionality, although working within the main directory, was finding all the files in the backup directories, one level up. So I deleted one of them and they all disappeared. Not good. It seemed as though Ruby had created such a weird directory that copying it actually resulted in a symlink instead.

Now I’ve got even worse file problems. A Flickr desktop app has to launch the browser to allow the user to authorise the application and to do so I used Launchy. But I noticed that it wasn’t passing anything after the first param to the browser. Instead of Firefox opening:

it was actually opening:

To investigate this, I added some debug lines to the Launchy module which created a file on the desktop and wrote debug info to it. When I then right clicked on the file to open it in BBEdit, the finder crashed every time. Yet more Ruby weirdness. Seems Ruby has real problems with files on OS X.

That was the least of my problems though. I eventually traced through the Launchy module to the Application class, which was passing the URL to its find_application_class_for method. It only had one class registered, the Browser class, which then ran the URL through its handle method, which used URI.parse to verify the URL. All well and good so far. The full URL passed muster with Launchy. The whole shebang then ended up at Application::run, where it all went horribly wrong, with thte URL appearing in the browser minus most of its params. By here, Launchy had worked out what command to run. Only it hadn’t. It wasn’t launching a browser, such as Firefox, it was launching /usr/bin/open. Now, we all know what & means to unix!

yep, open was using Firefox to open IN THE BACKGROUND!

There are only two solutions to this. Either open it in quotes, or escape the &. Neither work as URI.parse then fails to verify the URL and Launchy falls over.

So there we have it. Half a day wasted on a completely undocumented module (the norm for Ruby), only to find out it’s prolly never been tested on OS X.

comments powered by Disqus