Require bug? (1.8.0)

Require is supposed to include each file only once, but if the same physical
file is accessed from different paths, it can get included multiple times. Is
this the correct behaviour?

Example 1

File a.rb
puts "a includes b"
require "b.rb"
puts "a includes c"
require “c.rb”

File b.rb
puts "b includes c"
require “c.rb”

File c.rb
puts “C INCLUDED”

$ ruby a.rb
a includes b
b includes c
C INCLUDED
a includes c

C included once.

Example 2:

Change file b.rb
puts "b includes c"
require “./c.rb”

$ ruby a.rb
a includes b
b includes c
C INCLUDED
a includes c
C INCLUDED

File c.rb is included twice.

Require is supposed to include each file only once, but if the same
physical file is accessed from different paths, it can get included
multiple times.

If you don't want this behaviour, how do you test that this is the same
physical file ?

Guy Decoux

Date: Wed, 3 Dec 2003 00:47:43 +0900
From: Andrew Walrond andrew@walrond.org
Newsgroups: comp.lang.ruby
Subject: require bug?? (1.8.0)

Require is supposed to include each file only once, but if the same physical
file is accessed from different paths, it can get included multiple times. Is
this the correct behaviour?

yes - see other posts. i’ve used something like this as a workaround before

a.rb
$lib_a = true

b.rb
$lib_b = true

c.rb
$lib_c = true
require ‘a’ unless defined? $lib_a
require ‘b’ unless defined? $lib_b

-a

···

On Wed, 3 Dec 2003, Andrew Walrond wrote:

Example 1

File a.rb
puts “a includes b”
require “b.rb”
puts “a includes c”
require “c.rb”

File b.rb
puts “b includes c”
require “c.rb”

File c.rb
puts “C INCLUDED”

$ ruby a.rb
a includes b
b includes c
C INCLUDED
a includes c

C included once.

Example 2:

Change file b.rb
puts “b includes c”
require “./c.rb”

$ ruby a.rb
a includes b
b includes c
C INCLUDED
a includes c
C INCLUDED

File c.rb is included twice.

ATTN: please update your address books with address below!

===============================================================================

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
STP :: Solar-Terrestrial Physics Data | NCEI
NGDC :: http://www.ngdc.noaa.gov/
NESDIS :: http://www.nesdis.noaa.gov/
NOAA :: http://www.noaa.gov/
US DOC :: http://www.commerce.gov/

The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”

/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================

If it’s on a filesystem which will tell you the inode no. of a file,
(ie: mot unix systems) then you can compare that and the device number.
Beyond that, it’d be a case of finding the physical path to the file and
comparing that. Although it falls down when you have say, loopback
filesystems and SUBST’d drives.

···

On Wed, Dec 03, 2003 at 12:55:47AM +0900, ts wrote:

If you don’t want this behaviour, how do you test that this is the same
physical file ?


Ceri Storey cez@necrofish.org.uk

Yes; similar to the usual c/c++ construct everybody uses…

#ifndef A_H
#define A_H

#endif

I assume that require’s “only loading once” capability was designed to remove
the necessity for this clunky stuff, but the simple ‘compare the filename’
implementation is such that it must be used with care.

Andrew Walrond

···

On Tuesday 02 Dec 2003 7:47 pm, Ara.T.Howard wrote:

c.rb
$lib_c = true
require ‘a’ unless defined? $lib_a
require ‘b’ unless defined? $lib_b

If it's on a filesystem which will tell you the inode no. of a file,
(ie: mot unix systems) then you can compare that and the device number.

Well, the problem here is that ruby run also on another systems (not only
un*x) and I'm not sure if it exist a portable way to retrieve inode and
device number.

Beyond that, it'd be a case of finding the physical path to the file and
comparing that. Although it falls down when you have say, loopback
filesystems and SUBST'd drives.

and you can have problems with links

Guy Decoux

Ceri Storey wrote:

···

On Wed, Dec 03, 2003 at 12:55:47AM +0900, ts wrote:

If you don’t want this behaviour, how do you test that this is the same
physical file ?

If it’s on a filesystem which will tell you the inode no. of a file,
(ie: mot unix systems) then you can compare that and the device number.
Beyond that, it’d be a case of finding the physical path to the file and
comparing that. Although it falls down when you have say, loopback
filesystems and SUBST’d drives.

Getting the inode will work on most unix systems. My guess is that
getting the physical path will work on Windows (for now anyway. I’ve
heard that they are thinking of adding symbolic links in longhorn).

Carl