Project

General

Profile

Actions

Bug #5721

closed

require_relative

Added by nocandor (rommel nocando) about 13 years ago. Updated about 12 years ago.

Status:
Rejected
Assignee:
-
Target version:
ruby -v:
-
Backport:
[ruby-core:41522]

Description

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.

Thanks
nr.

Updated by akr (Akira Tanaka) about 13 years ago

  • Status changed from Open to Feedback
Actions #2

Updated by nobu (Nobuyoshi Nakada) about 13 years ago

=begin
I'm uncertain of your case.

I imagined the following case, but this works.
$ mkdir bin lib
$ echo 'p :foo' > lib/foo.rb
$ ln -s ../lib/foo.rb bin/
$ echo 'require_relative "foo"' > bin/a.rb
$ ruby bin/a.rb
:foo
=end

Updated by akr (Akira Tanaka) about 13 years ago

  • ruby -v changed from ruby 1.9.2p136 (2010-12-25) [x86_64-linux] to -

2011/12/7 rommel nocando :

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

Actions #4

Updated by mame (Yusuke Endoh) about 12 years ago

  • Status changed from Feedback to Rejected

I'm closing this ticket because akr guessed that it is an intended behavior, and because of no OP's rebuttal.

--
Yusuke Endoh

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0