So apparently sometimes rails apps need to run on Windows. This can cause a few problems, especially if your code is dropping down to the command line for some of its tasks. It is extremely frustrating when you try to search for solutions to these problems and all you get are responses like: “Um, don’t run rails on windows.”

So here’s a handful of the issues I recently had to figure out all alone and by myself with barely any help from The Internet.

Be careful when dropping down to the command line.

If you are using Open3.popen3, install the win32-open3 gem. Otherwise you will get some funky errors that don’t make any sense.

Another not-so-obvious issue is that the block form of popen3 will always return nil on Windows. Go figure.

Also, be sure to use double-quotes for all command line arguments.

Use File.join and relative paths whenever you need a file path.

These are bad:

"/path/to/file"
"c:\path\to\file"

These are good:

File.join(File.dirname(__FILE__), "relative", "path", "to", "file")
File.join(RAILS_ROOT, "relative", "path", "to", "file")

Be explicit when opening binary files.

Usually File.read is enough if you want to read the full contents of a file and don’t care about what those contents are. But if that file is binary, and your code is running on Windows, you’ll get weird results sometimes. Be explicit instead:

File.open(my_file, 'rb') { |f| contents = f.read }

Capistrano 2.5.x does a bad xcopy call.

This is only a problem if you are using deploy_via :copy. You can either patch Capistrano, or revert to using version 2.4.x, which doesn’t check for windows and assumes you can use cp (so you better have cygwin installed if you go that route).

All in all, it’s not that hard to make sure your code can work on windows. None of these things involve runtime checks to see what OS you are on. Just take the time to be careful, then everything won’t blow up if you don’t get the final say on where your code is running.

You can leave a response, or trackback from your own site.