Behavior of -rsomegem differs from require 'somegem'

ruby-talk
1

I just encountered something today and I'm not sure if this should be
the expected behaviour. Most likely I'm doing something odd here. I
believe this only affects items require'd as gems.

    > ruby -v
    ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1]

    > cat j.rb
    require 'rubygems'
    require 'fastercsv'
    
    puts $:.sort.join("\n")
  
    > ruby j.rb
    .
    /opt/local/lib/ruby/1.8
    /opt/local/lib/ruby/1.8/i686-darwin8.9.1
    /opt/local/lib/ruby/gems/1.8/gems/fastercsv-1.2.0/bin
    /opt/local/lib/ruby/gems/1.8/gems/fastercsv-1.2.0/lib
    /opt/local/lib/ruby/site_ruby
    /opt/local/lib/ruby/site_ruby/1.8
    /opt/local/lib/ruby/site_ruby/1.8/i686-darwin8.9.1
    /opt/local/lib/ruby/vendor_ruby
    /opt/local/lib/ruby/vendor_ruby/1.8
    /opt/local/lib/ruby/vendor_ruby/1.8/i686-darwin8.9.1

Okay, that is all well and good, but how about if we put those require's
on the command line and use -e.

    > ruby -rubygems -rfastercsv -e 'puts $:.sort.join("\n")'
    ruby: no such file to load -- fastercsv (LoadError)

Hmm... odd (to me). Lets try something else

    > ruby -rubygems -e 'require "fastercsv"' -e 'puts $:.sort.join("\n")'
    .
    /opt/local/lib/ruby/1.8
    /opt/local/lib/ruby/1.8/i686-darwin8.9.1
    /opt/local/lib/ruby/gems/1.8/gems/fastercsv-1.2.0/bin
    /opt/local/lib/ruby/gems/1.8/gems/fastercsv-1.2.0/lib
    /opt/local/lib/ruby/site_ruby
    /opt/local/lib/ruby/site_ruby/1.8
    /opt/local/lib/ruby/site_ruby/1.8/i686-darwin8.9.1
    /opt/local/lib/ruby/vendor_ruby
    /opt/local/lib/ruby/vendor_ruby/1.8
    /opt/local/lib/ruby/vendor_ruby/1.8/i686-darwin8.9.1

Is this the expected behaviour that -rsomegem behaves differently than
'require "somegem"'. Is the handling of -r different than 'require'

enjoy,

-jeremy

···

--

Jeremy Hinegardner jeremy@hinegardner.org

2

I just encountered something today and I'm not sure if this should be
the expected behaviour. Most likely I'm doing something odd here. I
believe this only affects items require'd as gems.

[snip]

Is this the expected behaviour that -rsomegem behaves differently than
'require "somegem"'. Is the handling of -r different than 'require'

loading rubygems alters the Kernel#require method. -r doesn't actually
call Kernel#require, it directly invokes the underlying C function(s)
the method calls. Therefore, rubygems is incapable of changing the
behavior of -r.

···

On Wed, May 23, 2007 at 04:16:37AM +0900, Jeremy Hinegardner wrote:

enjoy,

-jeremy

--

Jeremy Hinegardner jeremy@hinegardner.org

3

Thanks!

-r using the underlying C function(s). That's the clarification I
needed.

enjoy,

-jeremy

···

On Thu, May 24, 2007 at 02:03:02AM +0900, Logan Capaldo wrote:

On Wed, May 23, 2007 at 04:16:37AM +0900, Jeremy Hinegardner wrote:
> I just encountered something today and I'm not sure if this should be
> the expected behaviour. Most likely I'm doing something odd here. I
> believe this only affects items require'd as gems.
[snip]
> Is this the expected behaviour that -rsomegem behaves differently than
> 'require "somegem"'. Is the handling of -r different than 'require'
>
loading rubygems alters the Kernel#require method. -r doesn't actually
call Kernel#require, it directly invokes the underlying C function(s)
the method calls. Therefore, rubygems is incapable of changing the
behavior of -r.

--

Jeremy Hinegardner jeremy@hinegardner.org