Alright, so I use RubyScript2Exe in conjunction with Tar2RubyScript in order to create a self-contained binary: the latter archives the script (main.rb, now init.rb) and its additional external classes (e.g., core/ccsettings.rb) into a tar file that, in turn, gets wrapped into a Ruby script which untars into the OS’s temporary directory upon execution. The former, then, “traces” the result and tries to figure out this way which additional libraries are needed that aren’t part of Ruby’s core (in my case, that’s socket, iconv, and so on), then copies those libraries into the tar file, copies Ruby and (in Cygwin’s case) cygwin1.dll (i.e., the runtime environment) and wraps all that into an executable.

Sound good? Well, aside from rather steep space requirements, it is. Distributing Ruby scripts like this is very useful. Hats off to Erik Veenstra’s work.

But, it doesn’t work.

That is, it works perfectly fine on OS X, but it doesn’t on Windows/Cygwin, and I’m primarily using it for Windows, so that’s more than just a bummer.

1. Tar2RubyScript plus Darwin (OS X): check.
2. RubyScript2Exe plus Darwin (OS X): check.
3. Tar2RubyScript on Cygwin (Windows): check (with one caveat, see below).
4. RubyScript2Exe on Cygwin (Windows): nuh-uh.

It is that very last thing that I need to get working, and I can’t seem to figure out why.

In addition, there’s the slight problem that, inside Cygwin (and regardless of whether you have Cygwin installed or not, this script will run inside its own Cygwin environment), $APPDATA (the path to what’s usually C:\Documents and Settings\[you]\Application Data; it’s localized, so you can’t make assumptions regarding its name: on German Windows, it’s C:\Dokumente und Einstellungen\[you]\Anwendungsdaten, and worse, admins can customize this path, so you must rely on this environment variable) is apparently not always set (yet right now, I tested again and it was), so the script will sometimes assume to be on Unix, and accordingly place the settings file in a completely wrong place. But I’m confident I’ll figure that one out somehow.

I first thought it had something to do with (lack of) keyboard input, because it crashed stating that there was input of nil (i.e. nothing), but no: when I took that out and left it up to socket input entirely, the app would simply hang/stall instead, and it’s not clear where either, as there’s no traceback.

Why must you be so complicated, Windows?

Update: The ‘hang’ was apparently just a lack of patience. Logging in and back out automatically works even with the RubyScript2Exe. The problem is definitely with keyboard input and happens even with something as simple as:

foo = $stdin.gets
puts foo

I have detailed the problem in this ruby-talk post.