[ruby-core:23720] [Bug #1573] $0 behaves unexpectedly

Issue #1573 has been updated by Morris Brodersen.


> As always, there may be some use case I am missing?

my own use case is a bit hacky and has only syntax advantages:
i'm trying to intercept certain command line arguments, for example
in "ruby foo.rb -test" i would intercept the "-test" and
exec "ruby ./.tests/t_foo.rb" (which is a test suite for foo.rb
previously generated). this is all done in the script "pre.rb"
which i require by the rubyopt environment var (-rpre.rb). it would
need $0 to easily get name of the executed script; there are even
hackier ways of course. i admit that this use case is probably not
very meaningful nor a good design idea. i'd personally like it,
though.

anyway, let us suppose there is no valid use case. you wrote:

> Further, though, I cannot see a valid use case where the
> script being required with -r *should* know the name of
> the assumed eventual script: to me, it implies a problem
> with the design and/or the separation of responsibilities.

we can take this a step further to find ourselves posing
the following questions:

1. is there any difference between -r'd and require()'d scripts
   regarding the script that is actually run? no, since we

2. we can then ask: is their a valid use case for
   require()'d scripts to know $0?

3. if not, is their any valid use case except the
   $0 == __FILE__ trick?

4. yet further, what is the point of having $0 if we only
   need it for the trick mentioned above?

the main thing that buggers me though is that $0 == "ruby"
comes totally unexpected. i would never expect it to hold
"ruby" (except when the file itself is named ruby), and i
don't think the average developer would.

i hope my points were clear enough.

regards, morris
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1573

----------------------------------------
http://redmine.ruby-lang.org