It seems to me when I run:
Find.find('/user/name/documents') {|path| puts path}
it returns all the directories in the reverse order. I was expecting
the directories to be returned in alphabetical order, but that doesn't
seem to be the case. Also, in one case it reads half of a directory's
files, then the sub dirs and then it finished reading the rest of the
directory it started in and finished writing them in the Puts
statement.
Am I missing something? How do you do get it to write out the
directories in alphabetical order?
That's just the way Fine.find works. My experience is that, for most applications, the order in which Find.find traverses directories doesn't cause problems. But it may not be the best way to get a deep list of the contents of a directory. Two alternatives you might try are
Note: this form of Dir.glob doesn't find dotted (hidden) files and Fine.find does (there is a flag you can set to get dotted files with Dir.glob).
Regards, Morton
···
On Mar 9, 2007, at 7:35 PM, Brad wrote:
New user question:
It seems to me when I run:
Find.find('/user/name/documents') {|path| puts path}
it returns all the directories in the reverse order. I was expecting
the directories to be returned in alphabetical order, but that doesn't
seem to be the case. Also, in one case it reads half of a directory's
files, then the sub dirs and then it finished reading the rest of the
directory it started in and finished writing them in the Puts
statement.
Am I missing something? How do you do get it to write out the
directories in alphabetical order?
You are probably using the wrong api. If you want to get a list of
files/directories in a single directory, you should use:
Dir.entries()
or
Dir.foreach() for more complex iterations.
Find does a recursive search across multiple directories (and
subdirectories).
That being said, files are read and returned as your OS does. So it
is up to you to sort them out into directories and not directories and
to sort them out. You can usually do that with arrays.
dir = Dir.pwd
···
On 9 mar, 21:33, "Brad" <bradask...@gmail.com> wrote:
New user question:
Am I missing something? How do you do get it to write out the
directories in alphabetical order?
#
# dirs and files sorted together
#
puts Dir.entries(dir).sort
#
# or... more complex...
#
dirs =
files =
Dir.foreach(dir) do |file|
next if file =~ /^\..?$/ # ignore . and ..
if File.directory?("#{dir}/#{file}")
dirs << file
else
files << file
end
end
dirs.sort!
files.sort!
puts dirs, "---", files
#
# or same, but simpler (more ruby-like)
#
all = Dir.entries(dir) - ['.', '..']
all.sort!
dirs = all.select { |x| File.directory?("#{dir}/#{x}") }
files = all - dirs
puts dirs, "---", files
As others said already, the order is dictated by how the OS returns entries. Here's another solution:
puts Dir['/user/name/documents/**/*'].sort
Kind regards
robert
···
On 10.03.2007 01:33, Brad wrote:
It seems to me when I run:
Find.find('/user/name/documents') {|path| puts path}
it returns all the directories in the reverse order. I was expecting
the directories to be returned in alphabetical order, but that doesn't
seem to be the case. Also, in one case it reads half of a directory's
files, then the sub dirs and then it finished reading the rest of the
directory it started in and finished writing them in the Puts
statement.
Am I missing something? How do you do get it to write out the
directories in alphabetical order?
You could also use a system call to the tools "which" or "locate" or "find" on *nix systems and pipe that to where you need it. Very DRY!
···
On Mar 10, 2007, at 4:44 PM, Morton Goldberg wrote:
On Mar 9, 2007, at 7:35 PM, Brad wrote:
New user question:
It seems to me when I run:
Find.find('/user/name/documents') {|path| puts path}
it returns all the directories in the reverse order. I was expecting
the directories to be returned in alphabetical order, but that doesn't
seem to be the case. Also, in one case it reads half of a directory's
files, then the sub dirs and then it finished reading the rest of the
directory it started in and finished writing them in the Puts
statement.
Am I missing something? How do you do get it to write out the
directories in alphabetical order?
Any and all help welcome.
That's just the way Fine.find works. My experience is that, for most applications, the order in which Find.find traverses directories doesn't cause problems. But it may not be the best way to get a deep list of the contents of a directory. Two alternatives you might try are
Here's a little something I happened to stumble upon yesterday though. I
think these are pretty sound arguments against calling external
commands, when you have the choice. Might want to take them into
consideration.
On Sat, 2007-03-10 at 18:10 +0900, John Joyce wrote:
You could also use a system call to the tools "which" or "locate" or
"find" on *nix systems and pipe that to where you need it. Very DRY!
On Mar 10, 2007, at 4:44 PM, Morton Goldberg wrote:
> On Mar 9, 2007, at 7:35 PM, Brad wrote:
>
>> New user question:
>>
>> It seems to me when I run:
>> Find.find('/user/name/documents') {|path| puts path}
>>
>> it returns all the directories in the reverse order. I was expecting
>> the directories to be returned in alphabetical order, but that
>> doesn't
>> seem to be the case. Also, in one case it reads half of a
>> directory's
>> files, then the sub dirs and then it finished reading the rest of the
>> directory it started in and finished writing them in the Puts
>> statement.
>>
>> Am I missing something? How do you do get it to write out the
>> directories in alphabetical order?
>>
>> Any and all help welcome.
>
> That's just the way Fine.find works. My experience is that, for
> most applications, the order in which Find.find traverses
> directories doesn't cause problems. But it may not be the best way
> to get a deep list of the contents of a directory. Two alternatives
> you might try are
>
> BASE = '/Users/mg/Downloads'
>
> paths =
> Find.find(BASE) { |path| paths << path }
> puts paths.reverse
>
> or
>
> Dir.glob("#{BASE}/**/*") { |path| puts path }
>
> Note: this form of Dir.glob doesn't find dotted (hidden) files and
> Fine.find does (there is a flag you can set to get dotted files
> with Dir.glob).
>
> Regards, Morton
>
Indeed! Those should always be considerations when making calls to external binaries. But given those considerations, no need to repeat things. Fact is, many things are ported easily because of such binaries being pretty standard on *nix systems.
You could also always bundle those with it (if the licensing allows). Point is, if you don't have to write something, don't do it.
I'm talking about duct tape, pretty much like what Perl is often used for. (no offense to anyone, but I couldn't care less what anyone does with windows, this sort of thing will work on most *nixes and a windows DOS command should exist as well, it's part of porting. At some level there are dependencies to care about and you can't support ever version of every platform, it's just impossible.)
As for being a security risk, well, if you have Ruby executables then you already have the same level of risk as calling any binary on the system by any other means. You can't protect people from themselves.
Installers do this stuff all the time.
···
On Mar 10, 2007, at 6:20 PM, Choong Wei Tjeng wrote:
Here's a little something I happened to stumble upon yesterday though. I
think these are pretty sound arguments against calling external
commands, when you have the choice. Might want to take them into
consideration.
This link is for anyone new to Ruby. It's incredibly concise and well written. Apparently it was an internal style guide at Google. Whatever. It's a pretty good quick intro to what's in store for you in Ruby. You can use it as a gage of what you need to know. Especially useful if you've come from Perl.
On 3/10/07, John Joyce <dangerwillrobinsondanger@gmail.com> wrote:
This link is for anyone new to Ruby. It's incredibly concise and well
written. Apparently it was an internal style guide at Google.
Whatever. It's a pretty good quick intro to what's in store for you
in Ruby. You can use it as a gage of what you need to know.
Especially useful if you've come from Perl.
Thanks for the link. That really is a fine document. The only thing I
spotted that I'd change is the recommendation to put all require and
include statements at the top of a file, before class definitions.
With requires it usually (though not invariably) makes sense, but with
includes it doesn't, since they pertain to specific classes.