156

The latest changesets to Ruby 1.9.2 no longer make the current directory . part of your LOAD_PATH. I have a non-trivial number of Rakefiles that assume that . is part of the LOAD_PATH, so this broke them (they reported "no such file to load" for all require statements that based off the project path). Was there a particular justification for doing this?

As for a fix, adding $: << "." everywhere works, but seems incredibly hacky and I don't want to do that. What's the preferred way to make my Rakefiles 1.9.2+ compatible?

Milele
  • 33
  • 4
John Feminella
  • 303,634
  • 46
  • 339
  • 357

7 Answers7

142

It was deemed a "security" risk.

You can get around it by using absolute paths 

File.expand_path(__FILE__) et al

or doing

require './filename' (ironically).

or by using 

require_relative 'filename'

or adding an "include" directory

ruby -I . ...

or the same, using irb;

$irb -I .
rogerdpack
  • 62,887
  • 36
  • 269
  • 388
  • 27
    I wound up using `require_relative`. Thanks. – John Feminella May 24 '10 at 22:50
  • 11
    Is this akin to most unixes not including the current directory in the path for running executables? – Andrew Grimm May 24 '10 at 23:56
  • 5
    `require './filename'` only works if your script is executed with the working directory set to the same directory that the script resides. This is often not the case in multi-directory projects. – mxcl Aug 02 '12 at 18:31
34

There's two reasons:

  • robustness and
  • security

Both are based on the same underlying principle: in general, you simply cannot know what the current directory is, when your code is run. Which means that, when you require a file and depend on it being in the current directory, you have no way of controlling whether that file will even be there, or whether it is the file that you actually expect to be there.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
  • 5
    I don't think that enforcing that two files be in the same location relative to each other is necessarily a bad requirement. If that were true, then we would have no use for directories. – John Feminella May 25 '10 at 12:11
  • 4
    @John Feminella: what does this have to do with putting files in paths relative to each other? The question is about putting them relative to `.`, i.e. the current working directory. If the user `cd` s into a different directory, the current working directory changes, and you now `require` *completely* different files depending on what directory the user happened to be in when he called your script. I don't think that's a good idea. – Jörg W Mittag May 25 '10 at 12:53
  • So to maintain a decent interface, you should do this? `$: << File.dirname(__FILE__)` – Joshua Cheek Sep 11 '10 at 22:07
  • 4
    @Joshua Cheek: Personally, I don't like that. (But please don't look at my older code, because it is *littered* with that kind of stuff :-) ). I simply *pretend* that the `lib` directory is on the `$LOAD_PATH` and then `require` all files relative to `lib`. In other words: I leave it to the administrator to figure out how to set up the `$LOAD_PATH` correctly. If you use RubyGems, that is trivial, because RubyGems automatically does it *for* you, and if you use Debian packages, then it's the package maintainer's job. All in all, it seems to work out quite nicely. – Jörg W Mittag Sep 11 '10 at 22:22
  • 8
    @Joshua Cheek: Also, as a sort-of counterbalance to removing `.` from `$LOAD_PATH`, Ruby 1.9.2 introduces `require_relative` which ... surprise ... `require` s a file relative to the location of the currently executing file (i.e. relative to `File.dirname(__FILE__)` ). – Jörg W Mittag Sep 11 '10 at 22:24
  • Hey there _all_. I was following this with some '_confusion_' and I think I've made the right cognitive leap in understanding now. Either by accident or design, Ruby was behaving in a truly dynamic way; in that when there was a dynamically evoked **require** some other file with similar name would get loaded. Most of the time with say a ***Nix** command the load context would be relative to the script or executable (per **require_relative**). As far as I can tell though, isn't this only a problem when a Ruby program _loads code dynamically_? – will Mar 03 '11 at 02:51
  • Just to clarify: "current directory" is the directory the *user* is in, not the directory the `require`-ing file is in? – Andrew Grimm Apr 04 '11 at 07:20
16

As others answers point out, it's a security risk because . in your load path refers to the present working directory Dir.pwd, not the directory of the current file being loaded. So whoever is executing your script can change this simply by cding to another directory. Not good!

I've been using full paths constructed from __FILE__ as an alternative.

require File.expand_path(File.join(File.dirname(__FILE__), 'filename'))

Unlike require_relative, this is backward compatible with Ruby 1.8.7.

Jonathan Tran
  • 15,214
  • 9
  • 60
  • 67
  • 4
    There's also this variation (which I personally find more readable): `require Pathname.new(__FILE__).dirname + 'filename'` – Tyler Rick May 06 '11 at 23:12
8

Use require_relative 'file_to_require'

Throw this in your code to make require_relative work in 1.8.7:

unless Kernel.respond_to?(:require_relative)
  module Kernel
    def require_relative(path)
      require File.join(File.dirname(caller.first), path.to_str)
    end
  end
end
Tyler Brock
  • 29,626
  • 15
  • 79
  • 79
6

'.' in your path has long been considered a bad thing in the Unix world (see, for example, http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html). I assume the Ruby folks have been persuaded of the wisdom of not doing that.

Rodger
  • 332
  • 1
  • 2
3

As Jörg W Mittag pointed out, I think what you want to be using is require_relative so the file you require is relative to the source file of the require declaration and not the current working dir.

Your dependencies should be relative to your rake build file.

Bad Request
  • 3,990
  • 5
  • 33
  • 37
Martin
  • 161
  • 1
  • 6
3

I found this to be a confounding change until I realized a couple of things.

You can set RUBYLIB in your .profile (Unix) and go on with life as you did before:

export RUBYLIB="."

But as mentioned above, it's long been considered unsafe to do so.

For the vast majority of cases you can avoid problems by simply calling your Ruby scripts with a prepended '.' e.g. ./scripts/server.

Dylan
  • 3,658
  • 1
  • 21
  • 12