[ruby-talk:21368] Re: nested require files need path internally

On 19/09/2001 at 10:12 AM [e-mail] wrote:
>I think we are talking different issues.  You're talking about a
>program that spans multiple files.  I'm talking about the danger of
>loading from the current directory.  If your program contains
>
>  require './foo.rb'
>
>and what if the program is invoked in a directory that you don't
>expect, and that happend to contain the file named foo.rb, and that
>foo.rb has the following line?
>
>  system "rm -rf $HOME"
>
>So forget about the current directory.  Multiple files should be read
>from the absolute directory.  I recommend you to prepend application
>specific directory to the $LOAD_PATH in the main file.
>
>|Now consider that Foo inherits from or otherwise depends on Bar.  Then in
>|Foo.rb, I'm likely to put:
>
><snip>
>
>You don't have this kind of problem, if you don't try to load from the
>current directory.

But, I think what he is looking for is the ability to require a file from the same directory as the file that does the require, not from the current directory.  I have experienced this problem too...

If I have a whole bunch of files in site_ruby/libName then every file in that directory will have a series of

require "libName/filename"

lines.  Also, any file that wants to use my library will have similar require lines at the top.

Now, if I decide I want to rearrange things and want to move site_ruby/libName to site_ruby/companyName/libName to keep all the files from my company together, not only do the applications need to change their require lines (this is to be expected), but I have to go through every file in my library and change all those require lines.

I understand your point about the security implications of requiring files from the current directory, but it seems that if a file is requiring another file in the same directory as itself, then if a person can get into that directory to change the file being required, they might as well just have changed the file doing the require in the first place.

Julian