2011/12/7 rommel nocando <redmine / ruby-lang.org>:

> Bug #5721: require_relative
> http://redmine.ruby-lang.org/issues/5721
>
> Our users have found that with synchronicity's (a revision control system) populating with  -share option that the symbolic links break require_relative
>
> bin/launchLib.rb:54:in `require_relative': no such file to load -- /blah/sync_cache2/s0d/simParse (LoadError)
>
> The symbolic link is right on the file
>
> eg. symParse.rb ->/blah/sync_cache2/s0d/simParse.rb
>
> It will in fact follow links when the its at the directory level just not on the file.
>
> We have a work around by populating this so the link is not on the file.
>
> We would very much like a fix to this issue in future Ruby releases.
>
> Should be easy to reproduce.

I'm not sure how to reproduce the problem.
I don't know how symbolic link is used by the revision control system.

However I guess require_relative works as intended:
the argument of require_relative is a relative path from
the "real" file of the file which contains the require_relative call.

If there is a symbolic link to a file which calls require_relative,
the symbolic link is resolved before the relative path is resolved.

This helps a symbolic link to a working script which contains a
require_relative call.
If require_relative doesn't resolve the symbolic link,
the script doesn't work if it is invoked via the symbolic link.
-- 
Tanaka Akira