From: Daniel Berger <djberg96@...>
Date: 2007-02-17T05:30:06+09:00
Subject: Re: Found a Find.find() bug?

On Feb 16, 12:51 pm, ara.t.how...@noaa.gov wrote:
> On Sat, 17 Feb 2007, Robert Klemme wrote:
> > On 16.02.2007 18:15, Daniel Berger wrote:
> >> On Feb 16, 2:16 am, Robert Klemme <shortcut...@googlemail.com> wrote:
> >>> On 15.02.2007 23:25, robertlafe...@comcast.net 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.
>
> >> <snip>
>
> >> 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.
>
> > 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
>
> 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