Ignoring RUBYOPT?

ruby-talk
1

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...

No solutions? Anybody?

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?

gegroet,
Erik V.

E

2

> 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....
gegroet,
Erik V.

3

Erik Veenstra wrote:

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().

Have you checked for putenv()?

···

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....
gegroet,
Erik V.

4

you've tried this?

start rubyw.exe yourprogram.rb
exit

a dos box fires up but disappears right away..

http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

···

On Tue, 18 Jan 2005 08:31:05 +0900, you wrote:

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.

5

> > > 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().

Have you checked for putenv()?

Briliant idea! And yes, I've checked it. And no, it doesn't
exist...

gegroet,
Erik V.

6

> > > 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().

Have you checked for putenv()?

Brilliant idea! And yes, I've checked it. And no, it doesn't
exist...

gegroet,
Erik V.

7

Erik Veenstra wrote:

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().

Have you checked for putenv()?

Briliant idea! And yes, I've checked it. And no, it doesn't
exist...

gegroet,
Erik V.

I can smell a kind of sarcasm here ;-). Anyways, you are welcome.

You can also see into how you launch your ruby from FreePascal, some exec variants, like execve(), provide the ability to specify environment for a program you launch. I now recall this mentioned on some FreePascal forums. (Disclaimer: I do not know FreePascal, I do not program in Windows).

Sorry if it is of no help either,
Gennady.

8

"Erik Veenstra" <google@erikveen.dds.nl> writes:

> > > 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().

Have you checked for putenv()?

Briliant idea! And yes, I've checked it. And no, it doesn't
exist...

How about using something like this in your FreePascal program:

  Exec(GetEnv('COMSPEC'), '/C "set RUPYOPT=& \path\to\ruby ..."')

This uses the system command processor to execute the following two
commands (the ampersand is a command separator):

  set RUBYOPT=
  \path\to\ruby ...

Make sure that the equal sign after "RUBYOPT" touches the ampersand, or
else there will be a "RUBYOPT" variable in your environment that
contains a single blank. As long as the equal sign touches the
ampersand, this completely removes RUBYOPT from your environment before
invoking \path\to\ruby.

···

--
Lloyd Zusman
ljz@asfast.com
God bless you.

9

> > Have you checked for putenv()?
>
> Briliant idea! And yes, I've checked it. And no, it doesn't
> exist...

I can smell a kind of sarcasm here ;-). Anyways, you are
welcome.

Sorry... :wink:

You can also see into how you launch your ruby from
FreePascal, some exec variants, like execve(), provide the
ability to specify environment for a program you launch. I
now recall this mentioned on some FreePascal forums.
(Disclaimer: I do not know FreePascal, I do not program in
Windows).

execve is part of the Linux unit and of no use for us. There's
no equivalent in the Windows world. Some time ago, I switched
from exec of the Dos unit to executeprocess of the SysUtils
unit, because of the length of the command line (~4000 instead
of 255).

The problem with RUBYOPT is easily solved in the Linux universe
by executing a shell script in which RUBYOPT is set to nothing
before launching Ruby. There are no irritating DOS-box popping
up here. (It wouldn't be called "DOS-bos", anyway...) The
problem is really a problem in the Windows world. And it's
exactly the latter that has no execve...

Sorry if it is of no help either,

No problem. I'm getting used to it... :wink:

Gennady.

gegroet,
Erik V.

10

How about using something like this in your FreePascal
program:

Exec(GetEnv('COMSPEC'), '/C "set RUPYOPT=& \path\to\ruby
..."')

This uses the system command processor to execute the
following two commands (the ampersand is a command
separator):

On Windows 2000:

S:\>echo 1&echo 2
1
2

On Windows 98:

S:\>echo 1&echo 2
1&echo 2

That's not gonna work...

Thanks.

gegroet,
Erik V.

11

"Erik Veenstra" <pan@erikveen.dds.nl> writes:

How about using something like this in your FreePascal
program:

Exec(GetEnv('COMSPEC'), '/C "set RUPYOPT=& \path\to\ruby
..."')

This uses the system command processor to execute the
following two commands (the ampersand is a command
separator):

On Windows 2000:

S:\>echo 1&echo 2
1
2

On Windows 98:

S:\>echo 1&echo 2
1&echo 2

That's not gonna work...

Thanks.

Oh well ... [sigh]

You seem to have some rather restrictive constraints:

  - This must run under FreePascal, a language which doesn't
    seem to offer anything like setenv.

  - This must not make use of any auxiliary .BAT files.

  - This has to run under Windows 98.

Combining these limitations with the fact that ruby doesn't seem to
offer a way to ignore RUBYOPT, then it appears like you're stuck with
having to use some sort of ugly work-around, such as the nested ruby
solutions mentioned earlier.

In other words, it seems to be that your only option is to choose which
form of ugliness offends you the least.

Here's yet another piece of ugliness to consider:

I know you said no .BAT files, but would it fit within your restrictive
constraints to just create a temporary .BAT file, execute it, and then
delete it right away? Or is that also beyond the pale in your execution
environment?

If this is feasible, you can put this logic into your FreePascal
program:

  Open a file named "xxxxxxxx.bat" for writing, where "xxxxxxxx"
  is a unique string of valid filename characters.

  Write the following into that file:

    @echo off
    set RUBYOPT=
    \path\to\ruby program args ...

  Close the file

  Invoke this command:

    Exec(GetEnv('COMSPEC'), '/C call xxxxxxxx.bat')

  Delete "xxxxxxxx.bat"

This is no uglier than those nested ruby suggestions.

···

--
Lloyd Zusman
ljz@asfast.com
God bless you.

12

Hi,

At Tue, 18 Jan 2005 09:51:05 +0900,
Erik Veenstra wrote in [ruby-talk:126960]:

The problem with RUBYOPT is easily solved in the Linux universe
by executing a shell script in which RUBYOPT is set to nothing
before launching Ruby. There are no irritating DOS-box popping
up here. (It wouldn't be called "DOS-bos", anyway...) The
problem is really a problem in the Windows world. And it's
exactly the latter that has no execve...

You can do it as `env -u RUBYOPT'.

And, FreePascal can't call Windows APIs? If possible,
SetEnvironmentVariable() would be usable.

···

--
Nobu Nakada

13

Lloyd Zusman wrote:

Oh well ... [sigh]

You seem to have some rather restrictive constraints:

  - This must run under FreePascal, a language which doesn't
    seem to offer anything like setenv.

  - This must not make use of any auxiliary .BAT files.

  - This has to run under Windows 98.

Combining these limitations with the fact that ruby doesn't seem to
offer a way to ignore RUBYOPT, then it appears like you're stuck with
having to use some sort of ugly work-around, such as the nested ruby
solutions mentioned earlier.

You could also hack the ruby interpreter, itself, and build yourself a
custom version of ruby that can (or does) ignore RUBYOPT.

Curt

14

You seem to have some rather restrictive constraints:

- This must run under FreePascal, a language which doesn't
seem to offer anything like setenv.

Correct. It's not impossible to switch to an other compiler,
but it has to be available on a couple of platforms (Windows,
Linux, Darwin, (Solaris)). That's restrictive as well. Besides
that, a lot of testing has to be done to ensure that everything
works still fine. It might as well introduce new shortcomings.
Is it worth the effort?

- This must not make use of any auxiliary .BAT files.

Correct.

- This has to run under Windows 98.

Correct. Preferably even on Windows 95.

Combining these limitations with the fact that ruby doesn't
seem to offer a way to ignore RUBYOPT, then it appears like
you're stuck with having to use some sort of ugly
work-around, such as the nested ruby solutions mentioned
earlier.

In the meanwhile, I've got a (not too ugly) work-around. Pure
Ruby. I'll post in a couple of minutes.

Exec(GetEnv('COMSPEC'), '/C call xxxxxxxx.bat')

Flashing screens. I like it! :wink:
Thanks for your ideas.

gegroet,
Erik V.

15

> The problem with RUBYOPT is easily solved in the Linux
> universe by executing a shell script in which RUBYOPT is
> set to nothing before launching Ruby. There are no
> irritating DOS-box popping up here. (It wouldn't be called
> "DOS-bos", anyway...) The problem is really a problem in
> the Windows world. And it's exactly the latter that has no
> execve...

You can do it as `env -u RUBYOPT'.

And, FreePascal can't call Windows APIs? If possible,
SetEnvironmentVariable() would be usable.

Doing system calls on a high level was one of the options I had
in mind. It is possible, but system calls are always OS
specific. EEE, like it is today, can be compiled on Linux,
Darwin and Windows, with the same (functional) result. That's
nice, I want to keep it that way.

If there were no working alternative, I could do it. But the
previous mentioned solution with the bootstrapping script (pure
Ruby) does work.

I'll concentrate on the bootstrapping solution right now.
Thanks.

gegroet,
Erik V.