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)
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)
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.