NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
File::Fu (Score:1)
I could never remember whether it was Path::Class or Class::Path for some reason. Plus there's that "just throw an error" thing and some weird business about manipulating filenames for a foreign operating system which seemed a oddly pervasive in the source. Thus: File::Fu.
Conditional for removing "." and ".." (Score:2)
Hi Schwern!
Your conditional reads: $_ ne '.' or $_ ne '..' but it is wrong, and should be either $_ ne '.' and $_ ne '..' or alterantively ! ($_ eq '.' or $_ eq '..'). Furthermore, a better, more idiomatic, way would be to use File::Spec->no_upwards.
Re: (Score:2)
Interesting, I didn't know about no_upwards.
Path::Extended (Score:1)
Path::Class may be a nightmare while testing modules under Win32, as it uses a native path separator, which is good sometimes but breaks tests if the author of the tests just compares a Path::Class object stringification with a path separated by forward slashes like this:
my $file = file('foo/bar');
like $file => qr|foo/bar|; # not ok for Win32 as $file becomes "foo\bar" there.
I'd rather recommend Path::Extended (or Path::Extended::Class if you prefer), which has almost the same API but always uses a forw
Re: (Score:2)
I think assuming everything on Windows will take Unix style paths is eventually going to bite you in the ass, and fall flat on its face on VMS, but I see why you'd want to normalize paths. It does make life simpler.
Path::Extended contains some great ideas, things like grep(), save() and copy_to(). It would be nice if Path::Extended was a subclass of Path::Class, but I see there's some issues with that [cpan.org].