[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Require when Executed file is required by another file.

Zev Blut

2/18/2005 11:24:00 AM

Hello,

My colleagues and I just encountered an interesting gotcha with
"require".

Put the following in a file called "req1.rb"

-------------- [req1.rb]
#!/usr/local/bin/ruby1.8 -w

puts "$0 #{$0}"
base = $0.split("/")
PATH = base[0...(base.size - 1)].join("/")

def jump
require "req2"
end

puts "Fun"

if __FILE__ == $0
puts "Require 1"
jump
end
---------- [req1.rb]

And then put the following in another file called "req2.rb"

---------- [req2.rb]
require "#{PATH}/req1"

puts "Require 2"
---------- [req2.rb]

Now run req1.rb from the full path.

Here is an example of my output:
========
$ /home/zev/projects/rubyplay/recurse_require/req1.rb
$0 /home/zev/projects/rubyplay/recurse_require/req1.rb
Fun
Require 1
$0 /home/zev/projects/rubyplay/recurse_require/req1.rb
/home/zev/projects/rubyplay/recurse_require/req1.rb:5: warning:
already initialized constant PATH

/home/zev/projects/rubyplay/recurse_require/req1.rb:7: warning: method
redefined; discarding old jump

Fun
Require 1
Require 2
=========

Notice that the __FILE__ == $0 gets called twice!
Also the fact that PATH and jump get redefined too...

Is there a way to easily stop this?

Thanks,
Zev


10 Answers

Nospam

2/18/2005 12:09:00 PM

0

It seems that although require normally makes sure a certain files only
gets included once require somehow doesn't take into account the file
the interpreter first included.

Regards,

Peter

Zev Blut

2/18/2005 12:59:00 PM

0

On Fri, 18 Feb 2005 21:09:47 +0900, Nospam
<news.home.nl-1@nospam.no-nonsense.org> wrote:

> It seems that although require normally makes sure a certain files only
> gets included once require somehow doesn't take into account the file
> the interpreter first included.

Exactly, but should this be the case?

Cheers,
Zev



Gennady

2/19/2005 6:20:00 AM

0


On Feb 18, 2005, at 4:59 AM, Zev Blut wrote:

> On Fri, 18 Feb 2005 21:09:47 +0900, Nospam
> <news.home.nl-1@nospam.no-nonsense.org> wrote:
>
>> It seems that although require normally makes sure a certain files
>> only gets included once require somehow doesn't take into account the
>> file the interpreter first included.
>
> Exactly, but should this be the case?

require provides a simple mechanism trying to prevent multiple file
loads -- it keeps loaded file paths in array $" just as given
(appending a proper extension - .rb, .so, etc. - if it is missing) and
does not load a file if the same path is already present in the array.
It is very easy to trick it by requiring the same file using different
paths, like in "test.rb", "./test.rb", "././test.rb".

In general, it is very hard and time consuming to determine that
different paths refer to the same file, so require does not even try to
pretend that it is robust.

Knowing how require works, you can easily implement some work around
for your particular case.

>
> Cheers,
> Zev
>
>
>

Sincerely,
Gennady Bystritsky



Zev Blut

2/21/2005 10:42:00 AM

0

Hello,

On Sat, 19 Feb 2005 15:19:59 +0900, Gennady Bystritsky <gfb@tonesoft.com>
wrote:

> In general, it is very hard and time consuming to determine that
> different paths refer to the same file, so require does not even try to
> pretend that it is robust.

It certainly appears to be a bit tricky. Although, it would be nice
if the executed program was added to $" so that it could prevent being
required again.


> Knowing how require works, you can easily implement some work around for
> your particular case.

The solution for the day is probably that my colleagues and I need to
make all executable programs thin wrappers that only require the main
code and implement the __FILE__ == $0 logic.

Best,
Zev


martinus

2/21/2005 11:01:00 AM

0

> In general, it is very hard and time consuming to determine that
> different paths refer to the same file, so require does not even try to
> pretend that it is robust.

Why not calculate a hash of the file and use this in the check. This
would make the whole thing independent from the actual path, and allows
to re-require a file if its content changes.

martinus



Zev Blut

2/21/2005 11:26:00 AM

0

On Mon, 21 Feb 2005 20:00:37 +0900, Martin Ankerl
<martin.ankerl@gmail.com> wrote:

>> In general, it is very hard and time consuming to determine that
>> different paths refer to the same file, so require does not even try to
>> pretend that it is robust.
>
> Why not calculate a hash of the file and use this in the check. This
> would make the whole thing independent from the actual path, and allows
> to re-require a file if its content changes.

Interesting solution! Although, I am sure some people may not like the
potential performance hit. Also the re-require could be good and it
could be bad, depending upon various situations.

A coworker of mine just commented why not just use File.expand_path for
the required file? Is there any reason not to do this?

Cheers,
Zev





Joel VanderWerf

2/21/2005 7:42:00 PM

0

Zev Blut wrote:
> A coworker of mine just commented why not just use File.expand_path for
> the required file? Is there any reason not to do this?

Symlinks...

$ cd /tmp
$ touch foo
$ ln -s foo bar
$ ruby -e 'p File.expand_path("foo")'
"/tmp/foo"
$ ruby -e 'p File.expand_path("bar")'
"/tmp/bar"

It might not be very portable, but there is File::Stat#ino:

$ ruby -e 'p File.stat("foo").ino'
1239183
$ ruby -e 'p File.stat("foo").dev'
776
$ ruby -e 'p File.stat("bar").ino'
1239183
$ ruby -e 'p File.stat("bar").dev'
776


Zev Blut

2/22/2005 4:05:00 AM

0

On Tue, 22 Feb 2005 04:42:03 +0900, Joel VanderWerf
<vjoel@PATH.Berkeley.EDU> wrote:

> Zev Blut wrote:
>> A coworker of mine just commented why not just use File.expand_path for
>> the required file? Is there any reason not to do this?
>
> Symlinks...
>
> $ cd /tmp
> $ touch foo
> $ ln -s foo bar
> $ ruby -e 'p File.expand_path("foo")'
> "/tmp/foo"
> $ ruby -e 'p File.expand_path("bar")'
> "/tmp/bar"

Yes that is true, but I noticed if you actually go to directory with
a symlink, it will expand to the true path. Like so:

$ cd /tmp/
$ mkdir foo
$ ln -s foo bar
$ touch foo/baz.rb
$ ruby -e 'Dir.chdir("foo") ;p File.expand_path("baz.rb")'
"/tmp/foo/baz.rb"
$ ruby -e 'Dir.chdir("bar") ;p File.expand_path("baz.rb")'
"/tmp/foo/baz.rb"

Is this portable or are there other problems with doing it this way?

Best,
Zev


Joel VanderWerf

2/22/2005 6:19:00 AM

0

Zev Blut wrote:
> On Tue, 22 Feb 2005 04:42:03 +0900, Joel VanderWerf
> <vjoel@PATH.Berkeley.EDU> wrote:
>
>> Zev Blut wrote:
>>
>>> A coworker of mine just commented why not just use File.expand_path for
>>> the required file? Is there any reason not to do this?
>>
>>
>> Symlinks...
>>
>> $ cd /tmp
>> $ touch foo
>> $ ln -s foo bar
>> $ ruby -e 'p File.expand_path("foo")'
>> "/tmp/foo"
>> $ ruby -e 'p File.expand_path("bar")'
>> "/tmp/bar"
>
>
> Yes that is true, but I noticed if you actually go to directory with
> a symlink, it will expand to the true path. Like so:
>
> $ cd /tmp/
> $ mkdir foo
> $ ln -s foo bar
> $ touch foo/baz.rb
> $ ruby -e 'Dir.chdir("foo") ;p File.expand_path("baz.rb")'
> "/tmp/foo/baz.rb"
> $ ruby -e 'Dir.chdir("bar") ;p File.expand_path("baz.rb")'
> "/tmp/foo/baz.rb"
>
> Is this portable or are there other problems with doing it this way?

Hm, I didn't expect that. And also:

$ ruby -e 'Dir.chdir("bar") ;p Dir.pwd'
"/tmp/foo"

In the shell (using linux, zsh) it works differently:

$ cd bar
$ pwd
/tmp/bar

Another data point:

$ ruby -e 'Dir.chdir("bar"); puts `pwd`'
/tmp/foo

I guess ruby follows symlinks when doing Dir.chdir?

Anyway, it doesn't solve the problem of a symlinked .rb file, if that's
a problem.


Zev Blut

2/23/2005 5:49:00 AM

0

Hello,

On Tue, 22 Feb 2005 15:18:55 +0900, Joel VanderWerf
<vjoel@PATH.Berkeley.EDU> wrote:

> Zev Blut wrote:

>> Yes that is true, but I noticed if you actually go to directory with
>> a symlink, it will expand to the true path. Like so:
>> [Snip examples]
>>
> Hm, I didn't expect that. And also:
>
> [Snip more examples]
>
> I guess ruby follows symlinks when doing Dir.chdir?
>
> Anyway, it doesn't solve the problem of a symlinked .rb file, if that's
> a problem.

Yes unfortunately it does not...
Personally I use require with symlinks to directories, but not files.
Although, I am sure someone does require symlinked files.

Your File.stat suggestion looks good, but I just confirmed, as you
suggested,
that it is not portable to a Windows environment.

I suppose Martin Ankerl's suggestion of computing a hash of each file is
the
most robust.

Looking at the ToDo in Ruby I noticed this:

* save both "feature names" and "normalized path" in $"

Maybe, there is already a better solution and it just waits for
implementation :-)

Zev