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.
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 15.02.2007 23:25, robertlaferla@comcast.net wrote:
<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.
Regards,
Dan
···
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.
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 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 alib library exports this
alib.util.find('.', :follow => true) do |the_fully_expanded_path|
...
end
gem install alib
-a
···
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
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama
I'd vote to add support for a :follow option as well - just watch for
infinite loops. Got a patch?
Regards,
Dan
···
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
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
find2.rb (6.42 KB)
···
On Sat, 17 Feb 2007, Daniel Berger wrote:
I'd vote to add support for a :follow option as well - just watch for
infinite loops. Got a patch?
--
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama
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 2/16/07, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Sat, 17 Feb 2007, Daniel Berger 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
endFind2.find2('.', :follow => true) do |path, stat|
p [path, stat.mtime]
endthis on codeforpeople under alib, if you are looking in the future...
-a
--
we can deny everything, except that we have the possibility of being
better.
simply reflect on that.
- the dalai lama