Re: CPAN installing to somewhere not in @INC
That's key - you need to understand that the module is *not* in an incorrect location. It's in the correct location for the Perl it was installed under, and your current Perl avoids looking in that location for a good reason. Nothing is broken in that regard. What you need to figure out is why the CPAN shell is finding that module when it shouldn't. OK, I think I'm getting the idea. I have two version of Perl. Some modules are compiled with one version of Perl and won't work with the other. CPAN is running with the older version and reporting that everything's fine, but the scripts are running with the new version and for them, it's not. What would I do, for the sake of argument, if I really wanted to clean up my system and get rid of all traces of Perl 5.8.0 and its installed modules? I thought installing the latest Dev Tools and Perl 5.8.1 would make everything simple and make everything work but apparently not... Have You Validated Your Code? John Horner(+612 / 02) 9333 2110 Senior Developer, ABC Online http://www.abc.net.au/
Re: CPAN installing to somewhere not in @INC
On Jun 10, 2004, at 7:27 PM, John Horner wrote: CPAN is running with the older version and reporting that everything's fine, but the scripts are running with the new version and for them, it's not. That sounds like a PATH issue. Scripts begin with #!/usr/bin/perl, so they use that specific perl. But if you're starting the CPAN shell with 'perl -MCPAN -e shell', then that command will use the first perl to appear in your PATH. And if you're starting the CPAN shell with 'cpan', that script begins with a #! that points to the Perl it was installed with. Run 'echo $PATH' in a terminal to see what your PATH variable is set to. You could also use 'which perl' to see, well, which perl you're running. You could also run 'which cpan', and take a look at the first line of the script that shows you. And 'perl -v' will give you the Perl version - if that's different than '/usr/bin/perl -v', it's definitely a PATH mix-up. What would I do, for the sake of argument, if I really wanted to clean up my system and get rid of all traces of Perl 5.8.0 and its installed modules? 5.8.0? Did you follow Apple's old instructions for installing 5.8.0 on Jaguar, by any chance? If so, it's an easy fix - simply delete everything below /Library/Perl *except* for /Library/Perl/5.8.1 and its subdirectories. And if there's a perl binary and/or cpan script in your PATH before the ones in /usr/bin - I suspect there is, if you followed Apple's old directions, in /usr/local/bin - delete them. I thought installing the latest Dev Tools and Perl 5.8.1 would make everything simple and make everything work but apparently not... If you wanted simple you chose the wrong profession. ;-) sherm--
CPAN installing to somewhere not in @INC
This may be a frequently-asked question, but I've got installed modules which CPAN says are up to date but Perl can't find. @INC contains: /System/Library/Perl/5.8.1/darwin-thread-multi-2level /System/Library/Perl/5.8.1 /Library/Perl/5.8.1/darwin-thread-multi-2level /Library/Perl/5.8.1 /Library/Perl /Network/Library/Perl/5.8.1/darwin-thread-multi-2level /Network/Library/Perl/5.8.1 /Network/Library/Perl but when I look for HTML::TokeParser, I find it in /Library/Perl/darwin/HTML/TokeParser.pm so what should I do? I can't see exactly how CPAN (or a previous version of it) decided on that as the install location -- can I change the Config for CPAN to fix that? I know, of course, that I can have use lib to add that to @INC for each script, and I could presumably hack that for the Terminal environment somehow, but I'd rather not -- can I force that into @INC in some kind of system-wide way? One more question, sorry -- if I just copied the TokeParser.pm into the right dir, somewhere Perl *is* looking for it, would that be a problem? Assuming that modules are pure-perl, and don't involved header files and stuff, can I do this? Or will they misbehave because they find themselves in the 'wrong place' and I should just reinstall? Thanks for your patience, jh
Re: CPAN installing to somewhere not in @INC
On Jun 10, 2004, at 6:06 PM, John Horner wrote: This may be a frequently-asked question, but I've got installed modules which CPAN says are up to date but Perl can't find. @INC contains: /System/Library/Perl/5.8.1/darwin-thread-multi-2level ... snip ... but when I look for HTML::TokeParser, I find it in /Library/Perl/darwin/HTML/TokeParser.pm /Library/Perl/darwin is the architecture-specific directory for Perl 5.6 on Jaguar and older. Modules found there will not be compatible with the 5.8.1 version of Perl that you're using. so what should I do? I can't see exactly how CPAN (or a previous version of it) decided on that as the install location -- can I change the Config for CPAN to fix that? A previous version of Perl (correctly!) decided on that, not a previous version of CPAN. (The difference is a bit academic, I know, because CPAN.pm is bundled with Perl...) You cannot fix it because it is not broken. I know, of course, that I can have use lib to add that to @INC for each script, and I could presumably hack that for the Terminal environment somehow, but I'd rather not -- can I force that into @INC in some kind of system-wide way? You could, but that wouldn't allow Perl 5.8.1 to use modules compiled for 5.6. There is a reason that some modules are kept in version- and architecture-specific directories - they don't work with other Perl versions or architectures. One more question, sorry -- if I just copied the TokeParser.pm into the right dir, somewhere Perl *is* looking for it, would that be a problem? Yes. For one thing, there's more to this module than just the .pm file - there's also a .bundle, and there might be some autoload (.al) files or affiliated module (.pm) files as well. Assuming that modules are pure-perl That's an invalid assumption. The architecture-specific subdirectory exists for the purpose of providing a separate location for modules that are *not* pure-perl. Since HTML::TokeParser is in that directory, you should assume it's *not* pure-perl, but has an XS (i.e. a compiled C) component as well as Perl. Modules that are compiled for different major versions of Perl (5.6 vs. 5.8), and/or for different architectures (darwin vs. darwin-thread-multi-2level) are *not* compatible with other versions and/or architectures. So even if you did go to the trouble of figuring out what files to move, moving them wouldn't do any good. I should just reinstall? I'd use a scalpel first, and save the axe for a last resort. ;-) The key question is why the CPAN tool is claiming that this module is up to date when in fact it is not. How are you starting it, with 'cpan' or with 'perl -MCPAN -e shell'? Whichever one you're using, try the other to see if you get the same results. Is there a PERL5LIB in your environment? That's key - you need to understand that the module is *not* in an incorrect location. It's in the correct location for the Perl it was installed under, and your current Perl avoids looking in that location for a good reason. Nothing is broken in that regard. What you need to figure out is why the CPAN shell is finding that module when it shouldn't. sherm--
