hsmyers has asked for the wisdom of the Perl Monks concerning the following question:
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:
The quote from the PAUSE report is: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'); }
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.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.
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!
--hsm
"Never try to teach a pig to sing...it wastes your time and it annoys the pig."
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Finding files relative to a module
by GrandFather (Saint) on May 15, 2011 at 05:38 UTC | |
Re: Finding files relative to a module
by John M. Dlugosz (Monsignor) on May 15, 2011 at 04:26 UTC | |
Re: Finding files relative to a module
by Khen1950fx (Canon) on May 15, 2011 at 04:33 UTC | |
Re: Finding files relative to a module
by wind (Priest) on May 16, 2011 at 20:30 UTC | |
Re: Finding files relative to a module
by Anonymous Monk on May 17, 2011 at 06:36 UTC | |
by hsmyers (Canon) on May 17, 2011 at 06:45 UTC |