Re: Found a Find.find() bug?

Sorry, there was a typo in my e-mail. One should be “/tmp” and the
other should be “/tmp/” And yes, I am using this on Mac OS X where /tmp
is a symlink to /private/tmp. Should Ruby care about symlinks? IMHO,
it should work whether or not it is a symlink or not.

On 15.02.2007 23:25, [email protected] wrote:

Sorry, there was a typo in my e-mail. One should be “/tmp” and the other should be “/tmp/”
And yes, I am using this on Mac OS X where /tmp is a symlink to
/private/tmp.
Should Ruby care about symlinks? IMHO, it should work whether or not
it is a symlink or not.

That’s not Ruby’s fault - it’s the way filesystems work on Unix. Moral,
if your directory can be a symlink you should use Find.find("/tmp/.").
Note that there are good reasons to not follow symlinks by default.

But having similar options find’s option “-follow” and friends might
make up a good feature request for Find. Alternatively we could have
another method added, kind of complementary to prune which will add the
current file to the processing chain.

sample

Find.find “/foo/bar” do |file|
puts file

no effect if not a symlink,

but if a symlink to a dir

descend that dir now

Find.follow
end

What do others think?

Kind regards

robert

On 16.02.2007 18:15, Daniel B. wrote:

debatable.

If nothing else we should add a note in the documentation about
symlinks.

My point was that both behaviors have their place and changing it to
always follow does not improve the situation. Actually I find the
current behavior (not following symlinks) better as a default so there
should be an option to do follow if needed (command line “find” does it
similarly).

Kind regards

robert

On Sat, 17 Feb 2007, Robert K. wrote:

That’s not Ruby’s fault - it’s the way filesystems work on Unix.
Changing it to just File.stat would make it behave as the OP expected.

Kind regards

robert

my alib library exports this

alib.util.find(’.’, :follow => true) do |the_fully_expanded_path|

end

gem install alib

-a

On Feb 16, 2:16 am, Robert K. [email protected] wrote:

On 15.02.2007 23:25, [email protected] wrote:> Sorry, there was a typo in my e-mail. One should be “/tmp” and the other should be “/tmp/”

And yes, I am using this on Mac OS X where /tmp is a symlink to
/private/tmp.
Should Ruby care about symlinks? IMHO, it should work whether or not
it is a symlink or not.

That’s not Ruby’s fault - it’s the way filesystems work on Unix.

No, it’s because of this line in find.rb:

if File.lstat(file).directory? then

Since File.lstat reports on the symlink itself, and a symlink isn’t a
directory, it never enters this block.

Changing it to just File.stat would make it behave as the OP expected.
Whether or not this is what it ought to do in the first place is
debatable.

If nothing else we should add a note in the documentation about
symlinks.

Regards,

Dan

On Sat, 17 Feb 2007, Daniel B. wrote:

I’d vote to add support for a :follow option as well - just watch for
infinite loops. Got a patch?

attached.

p Find2.find(’.’)

Find2.find(’.’, :follow => true) do |path|
p path
end

Find2.find2(’.’, :follow => true) do |path, stat|
p [path, stat.mtime]
end

this on codeforpeople under alib, if you are looking in the future…

-a

Thanks for doing this. I just ran into this problem today (Find
following
soft symlinks issue).

One thing I ran into is that Find2.prune does not work as expected.
Once
you run prune, it seems to prune everything back at the non-symlink
level.

I’ll have to look into it further to see if I can do anything about
this.

On Feb 16, 12:51 pm, [email protected] wrote:

do follow if needed (command line “find” does it similarly).

Kind regards

robert

my alib library exports this

alib.util.find(’.’, :follow => true) do |the_fully_expanded_path|

end

I’d vote to add support for a :follow option as well - just watch for
infinite loops. Got a patch?

Regards,

Dan

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs