Forum: Ruby getting rid of $0

The common idiom
 if __FILE__ == $0 then ...
gives bugs when $0 is not what one would expect, for instance under a
debugger, or in rubyscript2exe, etc.

There should be a primitive test
   if <nice name to be found> then...

On 7/2/07, Michel Demazure <michel@demazure.com> wrote:
> The common idiom
>  if __FILE__ == $0 then ...
> gives bugs when $0 is not what one would expect, for instance under a
> debugger, or in rubyscript2exe, etc.
>
> There should be a primitive test
>    if <nice name to be found> then...
>

require 'English'

if __FILE__ == $PROGRAM_NAME
  ...
end


Blessings,
TwP

Tim Pease wrote:
> require 'English'
> 
> if __FILE__ == $PROGRAM_NAME
>  ...
> end
> 
Does that solve the problem?  Isn't that vulnerable to the same issues
as just using $0?

On 7/2/07, Alex Young <alex@blackkettle.org> wrote:
> >
> > require 'English'
> >
> > if __FILE__ == $PROGRAM_NAME
> >  ...
> > end
> >
> Does that solve the problem?  Isn't that vulnerable to the same issues
> as just using $0?
>

You're correct! That does not solve the problem. :/

Hmmm ... the solution I use most often is to have a top-level function
that runs the application.  This top-level function is called by a
separate Ruby script.


class MyApp
  def self.run( args )
    new(args).run
  end
  ...
end

And in an executable file called "my_app"

#!/usr/bin/env ruby

require 'MyApp'
MyApp.run ARGV


I try to avoid the __FILE__ == $0 idiom when I distribute code. You
run into the problems the original poster pointed out, and rubygems
also wrappers up all your executables with it's own special calling
semantics (provides compatibility between windows / *nix).

Not the answer you want to hear, but, "don't do that".  Sorry :/

TwP

On Jul 2, 2007, at 11:11 , Alex Young wrote:

> issues as just using $0?
Solve what problem? The code is doing what you asked it to do, that
isn't a problem, that's programming.

The code clearly reads "if this file is the program" which is NOT the
case when run under a debugger. I'm not sure what rubyscript2exe
generates, but my guess is that can be solved on their end somehow. I
generally don't want that code to run when I'm poking around in a
debugger or something similar. If I do, I set the values inside the
debugger and don't worry about it.

On 7/2/07, Michel Demazure <michel@demazure.com> wrote:
> The common idiom
>  if __FILE__ == $0 then ...
> gives bugs when $0 is not what one would expect, for instance under a
> debugger, or in rubyscript2exe, etc.
>
> There should be a primitive test
>    if <nice name to be found> then...

rcov provides for this case a special switch --replace-progname that
does what the name says. Unfortunately, sometimes there's still a
mismatch between those two:
one is ./something.rb while the other is just something.rb. Therefore
I use the following variation of the idiom (I haven't checked this
under debugger or any other prog):

if File.expand_path(__FILE__)==File.expand_path($0)

I have posted a patch for ruby-prof that adds a similar switch and it
has been accepted.

Anyway, $0 seems to be a normal variable that you can set to anything
you want, so creating a small wrapper script should not be a problem.
E.g.

$0 = ARGV.shift
require $0

On Jul 2, 2007, at 3:03 PM, Jano Svitok wrote:

> Anyway, $0 seems to be a normal variable that you can set to anything
> you want, so creating a small wrapper script should not be a problem.
> E.g.
>
> $0 = ARGV.shift
> require $0


be careful, $0 is not a normal variable:

cfp:~ > cat a.rb
$0 = 'foobar'

puts `ps wwwaux|grep foobar`


cfp:~ > ruby a.rb
ahoward  10371   2.6 -0.1    29204   1388  p2  S+   12:41AM   0:00.01
foobar
ahoward  10372   1.4 -0.0    27728    584  p2  S+   12:41AM   0:00.00
sh -c ps wwwaux|grep foobar
ahoward  10374   1.2 -0.0    27368    448  p2  S+   12:41AM   0:00.00
grep foobar


it actually assigns to c's argv


-a