Re: Favourite modules April 2003

[PodMaster]

I too am leaving out modules I maintain (btw I contribute on a lot of my faves )...

1. Wx -- aaaaaw yeah!!!!!!!
2. ExtUtils::Installed -- I use this a LOT
3. PPM::Make -- this one as well
4. ExtUtils::ParseXS -- this should be core (this is how xsubpp should be done)
5. CGI::Wiki::Simple -- not bad, could be better ;)
6. File::Spec -- portability, damn I like it
7. Regexp::Common -- beginning to like it a lot
8. Mail::Box -- it's getting better
9. Audio::Beep -- fun ;D
10. Module::Dependency::Grapher -- also fun
11. CGI::Application -- I still love it ;)
12. DB_File and/or BerkeleyDB -- and these, but you knew that ;D

There are a couple of others that could be on my list, but are currently unfinished, so they are not (CPANPLUS for example, or Test::Smoke).

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.

[barbie]

File::Spec -- portability, damn I like it

Except when it makes your life hell due to incompatability with other modules, as you have to regex everything into Unix style to get modules like File::Basename to work with it. Or try using with a file upload from an OS that isn't the same as the server. As a consequence I now avoid it like the plague.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Barbie
Birmingham Perl Mongers
Web Site: http://birmingham.pm.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[zby]

Could you add some more information about the incompatabillity prolem? I thought File::Spec was the way to go and I use it in one of my projects.

[PodMaster]

The trouble you seem to be having is because you haven't read the fileparse_set_fstype portion of the File::Basename docs. Anyway, I know its been a year since you wrote this, but I finally wrote fileparse (just for completeness) and thought I'd share.

sub File::Spec::dirname {
    my $self = shift;
    return $self->catpath( ( $self->splitpath(shift) )[ 0, 1 ] );
}

sub File::Spec::basename {
    my $self = shift;
    my $name = shift;
    return ($self->fileparse($name, map("\Q$_\E",@_)))[0];
}

sub File::Spec::fileparse {
    my $self = shift;
    my( $suffix, $path, $name ) = $self->splitpath(shift);
    $path = $self->catpath( $suffix, $path, '' );

    for my $s(@_){
        $self =~ s/($s)$//i and last;
    }

    $suffix = $1 ? $1 : undef;
    wantarray ? ( $name, $path, $suffix ) : $name;
}

Check out file.spec.basename.txt to test the above with the File::Basename test suite.

[kwilliams]

Maybe you'd like Path::Class better. I sure do, and I hope it isn't just because I wrote it. -Ken

[barbie]

This only hides File::Spec underneath the covers. I expect I'd still encounter the same problems as I did before, as it will still stringify to the OS you're on. As I use Windows mostly, it doesn't integrate with Find::Find and others without some meddling.

I have most problems with code written by others who aren't aware of the problems. Whether they use File::Spec or Path::Class, I don't see any difference between the return values being Windows style and then breaking when used directly in Find::Find or File::Basename. For them to work correctly you'll need to have:

$file->as_foreign('Unix')

all over the place, which kind of defeats the object of using Path::Class in the first place :(