Issue #5421 has been updated by Eric Hodel.


This is the first time you have mentioned that you are using a custom load manager.

As I've shown above with your req.rb example, a custom loader works fine with -r.  It is not a special case for RubyGems.  It is a problem of when your custom loader is loaded, not that it cannot work. 

You should file a new feature request like "RUBYOPT should be parsed before ARGV so require may be overridden".

You should include your req.rb, and the results of the following invocations:

  RUBYOPT=-r./req.rb ruby -rstringio -e0

  ruby -r./req.rb -rstringio -e0

You should ask for the output of both invocations to be identical.

Since -r no longer uses only rb_require() and will use an overridden Kernel#require this feature request should remain closed.
----------------------------------------
Feature #5421: -r option useless
http://redmine.ruby-lang.org/issues/5421

Author: Thomas Sawyer
Status: Rejected
Priority: Normal
Assignee: 
Category: core
Target version: 


Ran into a problem trying to require a plugin I had written while running a ruby scipt, e.g.

  $ ruby -rmyplugin script.rb

It tells me "no such file" for myplugin. Turns out the problem is that the -r option uses internal require code and thus circumvents rubygems or any modified #require, so even though my RUBYOPT="-rubygems", it makes no difference. I've also been informed that RUBYOPT is applied after -r options, which makes for an additional problem. Apparently this so -T can ignore RUBYOPT? But if that's the only reason, then -T should be preparsed from ARGV b/c having -r options load first prevents augmentation and use of what RUBYOPT loads by -r. RUBYOPT is supposed to set the environment, but it isn't much of an environment if its not there when I run a ruby command.

I've marked this report as a feature b/c I'm sure someone would take issue if I did otherwise, but I personally see it as a bug b/c it makes -r useless in many cases. 




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