From: Ron Jeffries <ronjeffries@...>
Date: 2002-01-11T23:44:20+09:00
Subject: Dir.entries have no home

Chet and I were writing a little code manager yesterday and we wrote
this code:

   def filesUnderManagement
      names = (Dir.entries(@directoryName).
          select { | each | ! (/.bak/ =~ each) }).sort
      names.reject { |each| FileTest.directory?(each) }
   end

The idea was to have all the file names that weren't named *.bak
(which is a thing TextPad does) and weren't directories.

So this seemed like reasonable code and passed all our tests. However,
as you may have noticed, being smarter than I am, the second line for
rejecting directories is looking at each name in the current working
directory, not the directory named in @directoryName.

This worked on my machine, but not on Chet's, so he found the problem:
we have to attach the directory name back to the file name before we
test it.

The same is true for opening it, and doing other things to it.

So it seems to us that the names that come out of Dir.entries are,
well, bad. They have lost their connection to their home, and as we
all know, when we lose our home we have lost everything.

Now one way I have dealt with this issue in the past is to go around
changing the working directory to whatever directory I'm thinking
about, but that seems to me to be a hack and a bug waiting to happen.

I seem to recall that VisualWorks or some Smalltalk had a Filename
object and (I'm guessing) that object knew its full name or directory
or equivalent.

So my questions are:

Where other than here should I have looked to see if these questions
already had answers?
Have others stumbled over this as well?
What do you do about it?
Is there a packaged solution already?
or Should we just write up what we need?

Thanks!

Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.