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.
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.
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
···
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:
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
···
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.
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
···
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.
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
···
On Tue, 22 Feb 2005 15:18:55 +0900, Joel VanderWerf <vjoel@PATH.Berkeley.EDU> wrote:
