in reply to why isn't current dir (".") in my @INC ?

Your use of the CPAN module modifies @INC. (Not that I have any idea why CPAN.pm does this, but it does.) To demonstrate:

sidhekin@blackbox:~$ perl -MData::Dumper -MCPAN -e 'print Dumper \@INC +' $VAR1 = [ '/usr/lib/perl5/5.8.8/i486-linux', '/usr/lib/perl5/5.8.8', '/usr/lib/perl5/site_perl/5.8.8/i486-linux', '/usr/lib/perl5/site_perl/5.8.8', '/usr/lib/perl5/site_perl/5.8.7', '/usr/lib/perl5/site_perl' ]; sidhekin@blackbox:~$ perl -MData::Dumper -e 'print Dumper \@INC' $VAR1 = [ '/usr/lib/perl5/5.8.8/i486-linux', '/usr/lib/perl5/5.8.8', '/usr/lib/perl5/site_perl/5.8.8/i486-linux', '/usr/lib/perl5/site_perl/5.8.8', '/usr/lib/perl5/site_perl/5.8.7', '/usr/lib/perl5/site_perl', '.' ]; sidhekin@blackbox:~$

Mystery solved? :-)

print "Just another Perl ${\(trickster and hacker)},"
The Sidhekin proves Sidhe did it!

Replies are listed 'Best First'.
Re^2: why isn't current dir (".") in my @INC ?
by tphyahoo (Vicar) on Feb 22, 2007 at 14:27 UTC
    Yes, sidhekin, mystery solved :)

    Well, at least solved enough that I can get the job done.

    If I move the "use" statements back so that CPAN is the last module "used", everything works as I want.

    Why CPAN behaves this way, and whether it should be considered a bug or a feature, is still open I suppose.

      Why CPAN behaves this way, and whether it should be considered a bug or a feature, is still open I suppose.

      Well, CPAN is used to update your system installation, so it seems pretty sensible to me for it to remove '.' from the search path. It doesn't want modules from just somewhere (and "." is somewhere) for modules to satisfy their dependencies, but only from perl's libdirs.

      --shmem

      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}