On Wed, 19 Sep 2001, Yukihiro Matsumoto wrote:

> Your statement is understandable.  I think it's trade off between
> library search path complexity and saving few strokes of grep and
> edit.  I prefer behavior simplicity this case.
>
> 							matz.

I definitely prefer simplicity.

However, this is a case, I think, where we have a tradeoff between
simplicity in the Ruby library and simplicity in the code that Ruby
developers write.  Remember that following code (Matz, [ruby-talk:21366]):

  system "rm -rf $HOME"

is dangerous.  Now, consider the solutions that have been proposed to the
problem of loading files from the same directory as the file that was
written.  I intend to show you that there is a real problem here that
needs to be addressed:

David Alan Black [ruby-talk:21298]:

  $:.unshift $:.pop
-or-
  require "./date"

The first of these depends on it only being done ONCE, and both have the
problem of possibly loading the wrong file, depending on what directory
the script was started from.

Michael Neumann [ruby-talk:20201]:

  $LOAD_PATH.unshift "."
  require "file"

A bit better than the last solution.  It has '.' in $LOAD_PATH twice, so a
little slower for trying to require files that don't exist, but that's
probably a non-issue.  However, this still does not address the security
issue.

Dave Thomas (Rubicon) [ruby-talk:20200], [ruby-talk:21337]:

  $: << File.dirname($0) << File.join(File.dirname($0), "..")

Now Dave doesn't have the current directory in the $LOAD_PATH, but he does
have the directory that the main script is located in.  This still allows
the wrong file to be loaded in the following cases:
  a) the script is required from a program that embeds Ruby but does not
     set $0 properly.
  b) a file in Rubicon requires another file that also modifies $:
  c) A rogue script is placed in the parent directory of where the script
     is run from (this can be solved by taking the latter
     File.join(...) out of $:).

I've proposed yet another solution [ruby-talk:20198]:

  def requirelocal(file, *args)
    caller_file, *foo = caller[0].split(':')
    caller_dir = File.dirname(caller_file)
    require File.join(caller_dir, file)
  end

This, IMHO, is the best solution out of the ones here, but it's still got
issues, since it depends on the formatting of caller() (though RCR#15
would help here).  It does help with the security issue, and it solves the
problem of requiring the same file twice, since the filename is
"normalized"  before it is required.

So we have five solutions from four people who write a LOT of Ruby code,
and none of the solutions are perfect.  This is a case where we have a
nontrivial problem to solve, and having each person solve the problem
independently:
  1) is buggy
  2) has security holes, and
  3) does not promote code re-use.

As Lars Christensen pointed out in [ruby-talk:21306]:

  C/C++                   Ruby
  #include <file.h>       require "file.rb"
  #include "file.rb"      ?

C/C++ has a way of requiring system headers and non-system (local)
headers, but Ruby only has a way to include system scripts.

Ruby has a hole here, and it needs to be filled.

Paul