Re^2: What would you like to see in a Virtual Filesystem for Perl?

It's an abstraction on the filesystem layer of your perl script, so that you can plug in other behavior than actually reaching out to the OS to access real files.

You'd want it for all the same reasons that you might use sshfs, gitfs, mount.cifs, etc. I thought I described the advantage of having it in userspace instead of kernel space fairly well in my post...?

Comment on Re^2: What would you like to see in a Virtual Filesystem for Perl?

Replies are listed 'Best First'.
Re^3: What would you like to see in a Virtual Filesystem for Perl? by harangzsolt33 (Deacon) on Mar 22, 2024 at 11:41 UTC
I see... Interesting. So, does this mean you have to overload builtin functions like open() and seek() to make this work?	[reply]
Re^4: What would you like to see in a Virtual Filesystem for Perl? by NERDVANA (Priest) on Mar 22, 2024 at 21:44 UTC
To be a 100% solution, I'd have to go one step further and intercept the C library calls. A 90% solution would be to intercept the Perl 'open' and 'opendir' and 'glob' opcodes. (once you have a file handle, you can tie it to intercept all the rest) But really, I'd be ok starting with a 60% solution of letting people opt-in by using a VFS module instead of calling 'open'. This is the point I was making about "have a Path::Class / Path::Tiny themed module" and "If "VFS::Path" happened to have your favorite API for traversing trees"	[reply]