( Just kidding!! :)

#!/usr/bin/perl
use strict;
use warnings;

my $h;

while (<DATA>) {
    chomp;
    s|^/|\$h->{'|;
    s|/|'}{'|g;
    s|([^']*)$|\0$1'} = 1;|;
    eval;
}

use Data::Dumper;
$Data::Dumper::Indent    = 1;
$Data::Dumper::Sortkeys  = 1;

open my $savedout, ">&STDOUT" or die $!;
close STDOUT;
open STDOUT, ">", \my $dump or die $!;

print Dumper $h;

open STDOUT, ">&", $savedout or die $!;

open my $fh, "<", \$dump or die $!;
while (<$fh>) {
    s/^(\s*)'/$1/;
    s/' =>.*//;
    next if /^\$|\s*}/;
    print;
}

__DATA__
/a/f1.mp3
/a/f2.mp3
/a/b/f1.mp3
/a/b/f2.mp3
/a/b/f3.mp3
/a/c/f1.mp3
/a/c/f2.mp3
/a/c/e/f5.mp3
/a/c/e/f6.mp3
/b/d/f4.mp3
[download]

Output:

  a
    f1.mp3
    f2.mp3
    b
      f1.mp3
      f2.mp3
      f3.mp3
    c
      f1.mp3
      f2.mp3
      e
        f5.mp3
        f6.mp3
  b
    d
      f4.mp3
[download]

I re-kid you, Almut: eval, untainted, unrestricted??

Could you do a quick replace of <DATA> with <>, with piped input from find for me, and then permit me a run of a single perl -e. Just before you execute your script?

:>>

(ok, it's _DATA_ and thus controlled, but it still hurts on reading. And worse, that one is pure evil to both speakers of Perl and non-speakers alike)

Update: to restrict the hurt to mere aesthtics, consider this safer version of the input loop, which will also survive pasted arbitrary absolute pathes from DATA/or a switch from DATA to STDIN.

my @f=();                                    # PJ
while (<DATA>) {
    chomp;
s|([^/]+)|do{$f[$#f+1]=$1,'$f['.$#f.']'}|ge; # PJ
    s|^/|\$h->{|;
    s|/|}{|g;
s|$|} = 1;|;                                 # PJ
#print; print "\n";
    eval;
}
[download]

food for thought

1. make 'tokenization' of filenames reuse 'tokens'
2. fix the loop to allow relative filenames (too trivial)
3. portability: also allow c:\data\no-such.fil
4. not a task, but an observation: use of Data::Dumper shows nicely the data structure of the recursive anonymous hash almut uses. This also demonstrates Perl's auto-vivication of the anonymous hashes we use hre: there's not one assignment of {}:
   $h->{$f[19]}{$f[20]}{$f[21]}{$f[22]} = 1;
5. a remark: normally you'd go for recursive functions when parsing a single path into a list of -> tree nodes. Or for a slightly less readable iterative 'unrolled' version of the same (keywords tail-recursion, loop-unrolling). The above code actually can be seen as such: everything but the s|/|}{|g; has been moved outside the loop, with the loop being reduced to just a looping regex substitution (/g modifier). Not much of a loop, not much for readability, and definitely not a sane nor a correct answer to give :)

...definitely not a sane nor a correct answer to give :)

Heh ;)

To my excuse I'd like to say that after a couple of hours Java coding this afternoon, I just had to do something real ugly for a change... to wake up my brain cells.  I hope you can forgive my sins...

The answer depends on what you want: ascii or html table output (consider embperl here) or just a suitable data structure before starting to think about output formatting issues..

As for the data structure itself, how about a a hash := anonymous hash | filename (as key use the basename of the dir | file; read as EBNF). In case of a reference, you're dealing with a directory (inner node of tree), otherwise with a file (leaf). Similar approach if you prefer an array instead.

A variant: KISS - is it suitable to use just the full dirpath as key? Then you can use a non-recursive approach: a hash of anonymous arrays.

cu
Peter

Updates: do check man perlref / perlreftut.

Thanks for replying.

A suitable data structure would be fine. I suppose I could manage creating the output from there.

Hi

I would consider using recursion since you have multiple levels of hierarchy.