"John W. Krahn" <jwkr...@shaw.ca> writes:
> Harry Putnam wrote:
>>
>> my %h1 = (
>> './b/f1' => 'f1',
>> './b/c/fa' => 'fa',
>> './b/l/c/f2' => 'f2',
>> './b/g/f/r/fb' => 'fb'
>> );
>>
>>
>> my %h2 = (
>> './b/fb' => 'fb', './b/c/fd'
>> => 'fd',
>> './b/l/c/f2' => 'f2',
>> './b/g/f/r/fc' => 'fc',
>> './b/g/h/r/fb' => 'fb'
>> );
>
> In your previous example you used two different paths, so why does
> this example have only one path and why do './b/l/c/f2' and
> ./b/g/f/r/fb' show up in both hashes but the other values do not?
About the single base path... it was just an oversite... the result of
copy pasting the first hash I typed out before I started fiddling with
them to get the problem a little more realistic... and never thought
to change the base path.
Your observation is right on the money though.. as in the real case
there are definitely two different root paths. In fact its really the
only reason to need two hashes.
Your second question is, again poor observation on my part... but
doesn't change the task really.
In fact, the base path is actually discarded in the final result.
base1/some/path/file
base2/path/file
Will actually be moved like this (roughly):
move:
base1/some/path/file
(minus the existing root)
to this path:
base2/path/file
(minus the existing root)
So: some/path/file
to: path/file
In here:
newbase/path/file
So doesn't the chore I tried for a simple example of remain the same?
That is, to identify which end file names are present in either hash
regardless of the rest of the path?
The example task was just to find the matching end names.
The task I'm after really has 2 major components... and a third
component that depends on those three for its input.
The actual project is a merging of two file structures that have many
similar files, many identical files, and many file in one but not the other.
One hierarchy is vastly larger than the other. Any files in it, but
not the smaller one, can be deleted.
Any files in the smaller one and not the larger need to remain in the
final product.
The problem gets more complicated with what is left.
Many are identical except for the path and I don't mean just the root
path.
So the name and paths in the larger structure that contain files
identical to files in the smaller structure... will be moved to
overwrite their twins in still a different root..
That is, we are building up a third hierarchy that contains a merger
of the 2 hashed structures in a specific way.
That isn't actually quite right either... really I'm trying to create
a list of cmds that will create such a merged structure.
No files are actually manipulated (yet) just drawing up a list of
things to do to create a merged structure.
Looking back at what I wrote above... its confusing as heck... sorry
I'm not better at explaining what I'm trying to do.
------- --------- ---=--- --------- --------
Of course first generate the hashes (in terms of File::Find).
h1{$File::Find::name} = $_
h2{$File::Find::name} = $_
so that the keys are File::Find::name and values are $_
1) find all files (end of path filenames) that are in one
and not the other
2) Ditto the other way round
3) Find all that match on end name (but maybe not path) and dispatch
them through means of a dispatch table, in one of 3 basic ways.
remove
add
overwrite twin
Part 3, I've actually got something of a handle on.. from other
helpful posts here regarding `dispatch tables'.
I'm looking for better ways to get 1 and 2 done with minimal effort.
I actually am able to get the needed results now... I was asking just
for better ways to do it and in the course of things provided somewhat
inaccurate examples as you've noted.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
