From: Sven Johansson <sven_u_johansson@...>
Date: 2005-12-31T20:06:44+09:00
Subject: Re: A few questions of function and style from a newbie

Robert Klemme wrote:

Thank you for your response! Quick and clarifying at the same time.

> Sven Johansson <sven_u_johansson@spray.se> wrote:

> No, you get the script's path - although this will incidetally match with
> the working directory when run in Windows (because the working directory
> defaults to the script directory).
>
> You want File.expand_path like in
>
> >> File.expand_path('.')
> => "/home/Robert"
>
> Now:
>
> working_dir = File.expand_path( Dir.getwd )
> script_dir = File.expand_path( File.dirname(__FILE__) )

Yes, indeed. All those work as advertised, even from the explorer
shell. Thanks!

> Your code in the first line has at least these problems:
>
> 1) You don't check for directories, i.e., you'll try to create MD5 of
> directories as well.
>
> 2) You don't close files properly.  You should use the block form of
> File.open - that way file handles are always closed properly and timely.
>
> Alternatives
>
> Dir['*'].each {|f| File.open(f,'rb') {|io| print f, " ",
> Digest::MD5.hexdigest(io.read), "\n" } if File.file? f}
>
> Dir['*'].each {|f| print f, " ", Digest::MD5.hexdigest(File.open(f,'rb')
> {|io| io.read}), "\n" if File.file? f}
>
> I can't reproduce the problem you state (identical digests) with the other
> lines of code.  I tried
>
> Dir['*'].each {|f|print f, " "; puts Digest::MD5.hexdigest(File.read(f)) if
> File.file? f}

Using:
require 'Digest/mp5'
Dir['*'].each {|f|print f, " "; puts
Digest::MD5.hexdigest(File.read(f)) if File.file? f}

gives

001.mp3 6ce4ad47bfa79b6c0e48636040c1dfb9
002.mp3 6ce4ad47bfa79b6c0e48636040c1dfb9
0022-042.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-043.ogg 5947035093bbfa22a9e7cf6e69b82a4e
0022-044.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-045.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-046.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-047.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-048.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-049.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-050.ogg 5947035093bbfa22a9e7cf6e69b82a4e
0022-057.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-058.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-059.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-061.ogg a7d6f03e275d69b363b9771c9d88e681
0022-062.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-069.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-070.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-071.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-072.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-073.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-074.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-077.ogg 4cac5ea5e666942920aff937aa9b3ee5
0022-078.ogg 5947035093bbfa22a9e7cf6e69b82a4e
[snip]

which clearly isn't good. However, both your suggestested alternatives
above work just fine. It would seem that binary mode really is a must
on Win32 - exhanging 'rb' for 'r' in those suggestions gives me the
hash repeat problem again. Good to know.

> But the problem here is that the file is not opened in binary mode which is
> a must for this to work.

Yes, so it would seem.

> It's not completely clear to me what you want to do here.  Apparently you
> check a number of audio files and shove them somewhere else based on some
> criterion.  What's the aim of doing this?

Oh, it works as it's supposed to do, so I'm not really trying to debug
it. It takes the hashes of all the files in a directory, compares them
to a global list of hashes, appends the new unique hashes to that list
and moves the corresponding files someplace, moves files that already
have "their" hashes in the list someplace else. The rest is just
morphing file names.

I was looking for more input along the line of "that's not how we do it
in ruby - this is how we would express this particular sort of
statement".

I realise that the first thing I should do is probably to read the
files by block instead of slurping them in wholesale, and that I would
be far better off maintainging the global list of hashes in a DB
instead of in a text file. I'll try my hands at the first, now that
I've gotten the hash and filehandle issue resolved above... as for the
second, taking a peek at this group reveals that making ruby talk with
mysql on Win32 isn't for the faint of heart, so I'll let that be for
now. 

Thanks again!
/Sven