Finding files relative to a module

[hsmyers]

In a module that has worked without error for a very long time, under Linux/Perl 5.8.1 I now get a warning about the following code:

package Chess::PGN::EPD;

use strict;
use warnings;
use Chess::PGN::Moves;
use File::Spec::Functions;
use Storable              qw( retrieve );
use Cwd                   qw( realpath );
use Try::Tiny             qw( try catch );

require Exporter;

my ( $hECO, $hNIC, $hOpening );
my %hash = (
    ECO     => \$hECO,
    NIC     => \$hNIC,
    Opening => \$hOpening
);

my $db_dir_qfn = realpath( catfile( __PACKAGE__, updir(), 'db' ) );

unless (-d $db_dir_qfn) {
    $db_dir_qfn = realpath('db');
}

The quote from the PAUSE report is:

Use of uninitialized value in -d at /home/sand/.cpan/build/Chess-PGN-E
+PD-0.28-WRroyj/blib/lib/Chess/PGN/EPD.pm line 22.
t/01_epdcode.t ...... ok
t/02_Storable.t ..... ok
Use of uninitialized value in -d at
    /home/sand/.cpan/build/Chess-PGN-EPD-0.28-WRroyj/blib/lib/Chess/PG
+N/EPD.pm line 22 (#1)
    (W uninitialized) An undefined value was used as if it were alread
+y
    defined.  It was interpreted as a "" or a 0, but maybe it was a mi
+stake.
    To suppress this warning assign a defined value to your variables.
    
    To help you figure out what was undefined, perl tells you what ope
+ration
    you used the undefined value in.  Note, however, that perl optimiz
+es your
    program and the operation displayed in the warning may not necessa
+rily
    appear literally in your program.  For example, "that $foo" is
    usually optimized into "that " . $foo, and the warning will refer 
+to
    the concatenation (.) operator, even though there is no . in your
    program.

Line 22 is the unless (-d $db_dir_qfn) { line. I'd check to see just what is going on, but I'm flying blind until I replicate the test environment---in other words it works fine on all other Perls and under Windows of any type since 2K.

I've been pointed towards File::ShareDir and its associated modules but I found the documentation pretty much opaque (at least to me) leaving me hoping for a 'relative files for dummies' how-to. I'd certainly settle for an example based on the code fragment shown above :)

Note: I should point out that I realize that this is a warning, not an error. In addition, the code still manages to work in that all of the tests that depend on the presence of the data base files all work as designed. (Yes, I'm puzzled myself as to why it works given the warning...)

Update: A large single thanks to your collective wisdom. I am handicapped by the lack (for now) of a Linux box to test on. Had I one, I would have hit this with the appropriate size stick until the problem was solved. That said, I would have missed your observations and probably not have produced as accurate a solution. The observation about undef and that __PACKAGE__ was a wash point me in the correct direction. We'll see---again thanks much!

[GrandFather]

Looks like you are hoping that catfile( __PACKAGE__, updir(), 'db' ) will find the folder 'db' relative to the folder containg the .pm file. However __PACKAGE__ is Chess::PGN::EPD which is unlikely to be what you mean and updir() removes it in any case so the catfile call is effectively catfile('db') which returns 'db' without the context you seem to be hoping for.

A technique that may help is to look up %INC for the module entry:

my $modulePath = $INC{'Chess/PGN/EPD.pm'};

which will give a relative or absolute path (depending on where the module is) ending in 'Chess/PGN/Moves.pm'. That is, the file name will need to be stripped off the end of the path. Something like the following may work:

...
use File::Spec::Functions qw(rel2abs splitpath updir catdir);
use Cwd qw(realpath);

my $loadPath   = rel2abs ($INC{'Chess/PGN/EPD.pm'});
my @parts      = splitpath ($loadPath);
my $db_dir_qfn = realpath (catdir (@parts[0, 1], updir(), 'db'));

[John M. Dlugosz]

Apparently, realpath( catfile( __PACKAGE__, updir(), 'db' ) ) is producing undef.

Look up and see under what conditions realpath will be undef. Maybe it's being fed undef as one of its arguments?

In any case, what do you really want to do if that value is undef? I'm guessing your logic is that if the directory by that name exists use it, or else use realpath('db'). If it has trouble even figureing out the proposed directory, that is in the same boat, right?

So make it:

unless (defined $db_dir_qfn && -d $db_dir_qfn) {

In any case, perhaps the problem isn't that the code finding the directory behaves any differently, but that -d used to not warn and now it does? It might has simply said "no, that's not a valid directory" when fed undef before. You can look that up in perldelta or just try it on your existing Perl installation.

Note that you can write it more concisely as:

$db_dir_qfn = realpath('db') unless defined $db_dir_qfn && -d $db_dir_
+qfn;

but then again, the test is the important part and maybe it should still go up front:

defined $db_dir_qfn && -d $db_dir_qfn
   or $db_dir_qfn = realpath('db');

saves the excess bracing.

[Khen1950fx]

I tried it with if ! instead of unless. Worked.

package Chess::PGN::EPD;

use strict;
use warnings;
use Chess::PGN::Moves;
use File::Spec::Functions;
use Storable qw( retrieve );
use Cwd qw( realpath );
use Try::Tiny qw( try catch );

require Exporter;

my ( $hECO, $hNIC, $hOpening );
my (%hash) = (
    ECO     => \$hECO,
    NIC     => \$hNIC,
    Opening => \$hOpening
);

my $db_dir_qfn = realpath( catfile( __PACKAGE__, updir(), 'db' ));
if ( -d !$db_dir_qfn  ) {
    $db_dir_qfn = realpath('db');
}

[wind]

GrandFather already explained why your code was not doing what you thought it was.

Here's an additional solution for achieving what you want though:

use Cwd qw(abs_path);
use File::Basename qw(dirname);

my $dirname = dirname(__FILE__);
my $db_dir_qfn = abs_path("$dirname/../db");

print "$db_dir_qfn\n";

[Anonymous Monk]

"Never try to teach a pig to sing...it wastes your time and it annoys the pig."

When monks take the time to write, give you code and documentation links, read them ... *****insert something clever about singing pigs here*****

[hsmyers]

After more than 10 years, you are just now getting annoyed by my sig? Gee, don't quite know what to say except thanks for the advice---I'll take it in the same spirit it was given :) Oh, enjoy the sig one more time...