Ignoring RUBYOPT?

Lähettäjä: "Erik Veenstra" <google@erikveen.dds.nl>
Aihe: Re: Ignoring RUBYOPT ?

> > How can I let Ruby ignore RUBYOPT?
> >
> > Both -T1 and unsetting the environment variable aren't
> > possible in my situation. I don't want the rest of the
> > script to run in safe mode 1 and I don't have control of
> > the environment...
>
> I haven't followed this thread, but since the internal ENV
> only affects the current process and its children, can you
> wrap your program in a script that unsets RUBYOPT and then
> just fork/popen the real program?

No, I can't. I start ruby.exe from a little FreePascal program,
which does have getenv(), but no such thing as setenv().

Using an intermediate .bat file isn't an option, because I
don't want a stupid DOS-box when using rubyw.exe instead of
ruby.exe.

Mmhh... I might use an intermediate Ruby script to unset the
environment variable... Not pretty, but it might work....

Right. Have FreePascal run e.g. 'ruby wrapper.rb realprogram.rb args'
and then wrapper.rb unsets the var and forks to run realprogram.rb. I
think it should work.

gegroet,
Erik V.

E

> > How can I let Ruby ignore RUBYOPT?
> >
> > Both -T1 and unsetting the environment variable aren't
> > possible in my situation. I don't want the rest of the
> > script to run in safe mode 1 and I don't have control of
> > the environment...

Mmhh... I might use an intermediate Ruby script to unset the
environment variable... Not pretty, but it might work....

S:\>echo %RUBYOPT%
rubygems

S:\>type test1.rb
p [ENV.include?("RUBYOPT"), $SAFE]
system("ruby -e 'p [ENV.include?(\"RUBYOPT\"), $SAFE]'")

S:\>type test2.rb
ENV.delete "RUBYOPT"
p [ENV.include?("RUBYOPT"), $SAFE]
system("ruby -e 'p [ENV.include?(\"RUBYOPT\"), $SAFE]'")

S:\>ruby -T1 test1.rb
[true, 1]
[true, 0]

S:\>ruby -T1 test2.rb
[false, 1]
[false, 0]

It's the last line of the second test which is interesting.
Promising?

Still not pretty...

gegroet,
Erik V.

Right. Have FreePascal run e.g. 'ruby wrapper.rb
realprogram.rb args' and then wrapper.rb unsets the var and
forks to run realprogram.rb. I think it should work.

It's close, but not close enough. We have to work around the
fact that safe mode 1 means "Can't start processes from $PATH
if any directory in it is world-writable." That's done with:

ruby -r wrapper.rb -T1 empty.rb realprogram.rb args
See my previous (in time) posting.

Thanks.

gegroet,
Erik V.

> > > How can I let Ruby ignore RUBYOPT?
> > >
> > > Both -T1 and unsetting the environment variable aren't
> > > possible in my situation. I don't want the rest of the
> > > script to run in safe mode 1 and I don't have control
> > > of the environment...
>
> Mmhh... I might use an intermediate Ruby script to unset
> the environment variable... Not pretty, but it might
> work....

It's the last line of the second test which is interesting.
Promising?

Consider the following:

$ ruby -T1 test1.rb test2.rb

In which test1.rb (aka bootstrap script) does something like:

ENV.delete("RUBYOPT")
system("ruby #{ARGV.shift}")

.... and test2.rb is the real stuff.

It does work, really. But...

There's one potential problem, according to the Pragmatic
Programmer's Guide, $SAFE==1 means: "Can't start processes from
$PATH if any directory in it is world-writable.". So, it's not
guaranteed that the inner ruby can be launched.

I've tested this and it results in an "Insecure operation -
system (SecurityError)".

Still there?...

What about this:

$ ruby -r test1.rb -T1 test2.rb test3.rb

test1.rb is the above mentioned bootstrap script, test2.rb is
empty and test3.rb is the real stuff. Because "-T1" occurs
after "-r test1.rb", this test1.rb is run in safe mode 0, so it
can run any process it wants. test2.rb is there, because Ruby
needs an application script, not just "-r"'s and parameters.

The result of all this is that -T1 is encounterd after parsing
the commandine part which does the real work, but before the
end of the commandline where RUBYOPT is parsed! (Well, *not*
parsed, because, in the meanwhile, we run in safe mode 1.)

Bingo!!! It works!!!

What a hack!
What the heck!

I've to rethink it tomorrow... It's still not pretty...
gegroet,
Erik V.