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?
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
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
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
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.
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.
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.
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.