Similar. The difference is that Tie::Dir returns a stat for the value of each key. Tie::Filesystem returns another tied hash for directories. I haven't decided what to return in for files yet.
use Tie::Filesytem;
tie %root, Tie::Filesystem;
print "Perl Found!" if exists $root{usr}->{bin}{perl};
Cheers,
Erik
Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet
| [reply]
[d/l] |
You mean like a filehandle or a scalar? I'd like to be able to open a data file with $root->{tmp}->{data.txt}.
The idea of just reading and writing a file by assigning to a hash is very tempting, although getting a filehandle back might be better if it has to be passed to other functions.
If you add either, I could see myself using it heavily, not the least because it would allow me to transparently fake a filesystem. VFS perl style. Woo hoo!
| [reply] |
Actually, building a simple perl VFS on top of this was a plan from the begining
The reason that, say, $fs{etc}->{passwd} == '/etc/passwd' currently is because the downside of this interfece is that it is difficult to get the full pathname without walking back up the tree. Having the full path name gives the programmer flexibilty and keeps the thing light.
What about this: an optional argument to the tie is a closure. This closure takes the full path to a file, and returns some arbitrary scalar - a filehandle ref, the leafname, a Tie::File array ref, whatever. How's that sound?
Cheers,
Erik
Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet
| [reply] |
I have some XML data that's hierarcically orgainzed and stored within the filesystem. Each data file is relatively small. Slurping and writing the data back out using a hash assignment would make for a nice interface to my data.
A feature that allowed me to return a list of files filtered by access or change time would be also be useful.
| [reply] |