Re: An Interesting Gotcha With use/require
by japhy (Canon) on Feb 09, 2005 at 14:40 UTC
|
It is purely a case-sensitivity issue. To Perl, File::BaseName and File::Basename are two different namespaces. As modules, they would be handled by File/BaseName.pm and File/Basename.pm (ordinarily). To Windows, however, those two files are the same.
Perl won't load a module if it's already in %INC, but Perl doesn't see an entry for 'File/BaseName.pm', only for 'File/Basename.pm'.
For an interesting artifact of this anomoly, try running this code:
use Strict;
$foo = 10;
and see what happens. See if you can figure out why.
_____________________________________________________
Jeff japhy Pinyan,
P.L., P.M., P.O.D, X.S.:
Perl,
regex,
and perl
hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart
| [reply] [d/l] |
|
That runs silently for me.
I did a case-insensitive search for files, to check for any Strict.pm and only found "C:\perl\lib\strict.pm"
So, it must be loading strict.pm successfully as there's no errors/warnings, but 'strict' isn't catching the undeclared variable.
I'm stumped! What's going on then?
| [reply] |
|
| [reply] [d/l] [select] |
|
|
Re: An Interesting Gotcha With use/require
by dragonchild (Archbishop) on Feb 09, 2005 at 14:42 UTC
|
I just tried it on Solaris.
Can't locate File/BaseName.pm in @INC (@INC contains: ... )
Commenting out the use on File::BaseName and leaving in the one for File::Basename means that everything works fine.
I'm guessing you're right - it's an OS issue with case-sensitivity. VMS will probably have the same problem.
Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] [d/l] |
Re: An Interesting Gotcha With use/require (a fix)
by tye (Sage) on Feb 09, 2005 at 16:57 UTC
|
| [reply] |
|
| [reply] |
|
BEGIN { require Module; import Module LIST; }
and "import Module List" is "Module->import( List )", which is "using a class" even if 'Module' isn't object-oriented.
If you never use use, then that code will never matter.
| [reply] [d/l] [select] |
|
Re: An Interesting Gotcha With use/require
by fireartist (Chaplain) on Feb 09, 2005 at 17:02 UTC
|
Subroutine fileparse_set_fstype redefined at C:/Program
Files/Perl/lib/File/Basename.pm line 152 (#1)
(W redefine) You redefined a subroutine. To suppress this warning
+, say
{
no warnings;
eval "sub name { ... }";
}
Out of interest, does anyone know why the error message suggests wrapping "sub name { ... }" in an eval?
use strict;
use warnings;
sub foo { print 'x' }
{
no warnings;
sub foo { print 'y' }
}
foo();
...prints 'y' with no warnings for me. | [reply] [d/l] [select] |
|
In your code, the first and second sub are declared at compile time. But if you want to dynamically declare a subroutine at run time, you need to wrap it up in an eval block so that that particular piece of code is evaluated only at run time.
| [reply] |
Re: An Interesting Gotcha With use/require
by perrin (Chancellor) on Feb 09, 2005 at 15:04 UTC
|
I had just added a library function to my general use library when I suddenly started getting a redefined subroutine warning for File::Basename (see below) from a program that had been running warning free until that moment. Both the main program and the new library function specify use File::Basename.
That should not be a problem if your library declares a package name. Don't make perl4-style libs that just dump all their functions into your main program -- you will regret it.
It was always my understanding that use and require would not try to load a module a second time if it was already listed in %INC.
They will still call import() a second-time though. | [reply] |
|
| [reply] |
|
As you can read in the followup to perrins comment, his comment is totally irrelevant, and only causes confusion. Your problem occurs because a subroutine gets defined twice. It has nothing to do with importing. See my example further down the thread - the one subroutine that's being redefined isn't exported.
| [reply] |
|
|
|
|
That should not be a problem if your library declares a package name.
What do you mean by that? Note that File::Basename is a standard module whose first line reads:
package File::Basename;
The problem isn't the library. The problem isn't the code either. The problem is the underlaying filesystem.
To the OP: "Here's a nickle kid. Get yourself a better computer" | [reply] [d/l] |
|
Not File::Basename, but his library that uses it. There would not be any collision of imported names if that library was in a different namespace.
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
Re: An Interesting Gotcha With use/require
by jacques (Priest) on Feb 10, 2005 at 01:07 UTC
|
| [reply] |