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