[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

behavior of -rsomegem differs from require 'somegem'

Jeremy Hinegardner

5/22/2007 7:17:00 PM

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 Answers

Logan Capaldo

5/23/2007 5:03:00 PM

0

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.
> enjoy,
>
> -jeremy
>
> --
> ========================================================================
> Jeremy Hinegardner jeremy@hinegardner.org
>

Jeremy Hinegardner

5/23/2007 5:42:00 PM

0

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.

Thanks!

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


enjoy,

-jeremy

--
========================================================================
Jeremy Hinegardner jeremy@hinegardner.org