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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Full
Abbreviated
Hidden
• #### 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].