Any way that helps you understand is a good one. After all, this is Perl.<grin/>

However, I do have a few suggestions. I find that small utility functions often reduce the difficulty of reading code. For example, you repeat a snippet of code in three places to create a directory. I would probably define:

sub mkdir_if_needed
{
    my ($dir) = @_;
    return if -d $dir;
    mkdir($dir,0755) or
       warn "Could not mkdir: $!\n";
    return;
}
[download]

and then call it in multiple places. That reduces unnecessary noise in the code.

The outer loop can also be done as a Perl foreach loop (instead of the C-style you are using). The beginning of the loop would look like:

foreach my $dacdir ( @allDACDirs )
{
    my $curr_dir;
    my $entry;
    # Read the array and populate
    foreach $entry (@{$dacdir})

    ...
[download]

This removes the need for $array_no and $i.

A minor step into a more complex data structure would be to replace the strings above with anonymous arrays, so you don't spend time reparsing. I would have made the following replacements in the first array:

• "m:configapp1" would be [ 'm', 'configappl' ]
• "d:conf" would be [ 'd', 'conf' ]
• "f:dactest1" would be [ 'f', 'dactest1' ]
• "f:conf,4K_logging.properties" would be [ 'f', 'conf', '4K_logging.properties' ]

This is mostly because I tend to think in these kinds of structures. I might then suggest different characters for the two styles of f entries. One would not have the extra file entry and the other would.

This might tempt me toward a more table-driven approach for processing the entries... But, I'll stop here before the abstraction level gets too deep (and we have to break out the hip-waders<grin/>).