Embedded Ruby and stdin

[Lennon Day-Reynolds]

I'm working on a simple wrapper which embeds the Ruby runtime and a
script file into a single binary. The idea is to have something much
like Exerb, but platform-independent (i.e., works anywhere Ruby does).
It reads the size and offset of an included script from the last few
bytes of the program binary, closes stdin and reopens it as a handle
to argv[0], and seeks to the script offset before initializing Ruby.

Everything goes fine until I call ruby_options(argv, argc), at which
point I get an Errno::EINVAL exception. Does anyone with a little more
experience working with the Ruby core have any suggestions for why
this could be happening? I know that the filehandle is valid, since I
do a number of I/O ops on it from C before passing control to Ruby.

I know that I could just copy out the script data to another file, or
eval it as a string, but there are potential problems with that:
specifically, the fact that I'm trying to distribute binary files
along with my Ruby program, which will be added to the __END__ section
of the Ruby script before it is appended to the wrapper binary. Since
these files will be quite large (50-150MB), I want to avoid copying
them to another file, or loading them fully into RAM, if at all
possible.

Any ideas would be greatly appreciated. I can post code snippets first
thing tomorrow morning once I'm back at work; I just wanted to see if
anyone had any quick suggestions before that.

 

[Erik Veenstra]

I'm working on a simple wrapper which embeds the Ruby runtime
and a script file into a single binary. The idea is to have
something much like Exerb, but platform-independent (i.e.,
works anywhere Ruby does).

Do you know about RubyScript2Exe [1]? There's a (not yet
released) Linux version as well, both i386 and PPC. Most of it
must work (at least in theory) with MacOS.

It reads the size and offset of an included script from the
last few bytes of the program binary,...

So do I, kind of.

... closes stdin and reopens it as a handle to argv[0], and
seeks to the script offset before initializing Ruby.

That's interesting. Does your program replace the Ruby
executable, or does it include the Ruby executable? I've chosen
the latter option, but that's not an option if you want to do
this kind of tricks.

I know that I could just copy out the script data to another
file, or eval it as a string, but there are potential
problems with that: specifically, the fact that I'm trying to
distribute binary files along with my Ruby program, which
will be added to the __END__ section of the Ruby script
before it is appended to the wrapper binary.

Tar2RubyScript [2] works with "binary" data at the end of the
script as well, but it does read the input script into memory
(multiple times).

Since these files will be quite large (50-150MB), I want to
avoid copying them to another file, or loading them fully
into RAM, if at all possible.

Well, uh, that's big...

Any ideas would be greatly appreciated. I can post code
snippets first thing tomorrow morning once I'm back at work;
I just wanted to see if anyone had any quick suggestions
before that.

Just have a look at the 2 projects mentioned. They are pretty
mature. You might learn from them... And I may learn from
you...

Good luck!

gegroet,
Erik V.

[1] http://www.erikveen.dds.nl/rubyscript2exe/index.html
[2] http://www.erikveen.dds.nl/tar2rubyscript/index.html

 

[Lennon Day-Reynolds]

Erik,

Thanks for the pointers -- I had indeed looked at your projects, and
definitely considered using them. Given the large file size of the
binaries I'm including, though, as well as the fact that those
included binaries are themselves already compressed, I didn't want to
add another level of archiving to the process unless absolutely
necessary.

I do embed the full Ruby runtime, rather than simply packaging the
interpreter. This means I have to reproduce the functionality of the
normal interpreter, but it also means that for simple cases I don't
have to extract anything to the user's machine; I can just execute
scripts in-place from the binary.

I'm still experimenting at this stage, but this tool will be in
production use within the next few weeks, after which I'll try to talk
to my employer and see if we can get some of the code released.

Thanks for the advice.