On Mon, 2003-07-14 at 14:45, Tod Harter wrote: > On the general topic of Perl: > > I've been building and installing perl and perl based webapps for 9 years now. > Never ever had to tweak with @INC. It LOOKS nonsensical perhaps, but its only > purpose is to search through parts of the perl specific files to find modules > and libraries. The various things you see in there represent 'generic' places > where stuff could be installed, machine specific places, site specific places > (ie you could NFS mount at those points), as well as 'architecture specific' > (shareable only between certain systems like x86 linux with threads enabled).
Yep, that's clear from an examination of it. But it doesn't explain the apparent inability of an installed 5.8.0 to look in ../perl5/5.8.0 which is what puzzles me. > 2 features of @INC are useful to you as a perl user. 1st is that "." (the > current working directory of your script) is always included as the first I tried this when I saw it but even putting the whole of AxKit into /home/httpd (where Apache claims to be looking as ".") simply made it look elsewhere for more and yet more stuff that is clearly installed but which it cannot find. Probably to do with having multiple installs. > I have no direct experience with RH 9, but every report I've seen indicates > that RH made a total mess of perl on that distro. No surprises there either. They did the same with TeX. Goddess knows why. > If you want to 'rip out' > perl my advice would be 1st) install the latest RH RPM, then delete the > /usr/bin/perl and /usr/lib/perl5 from your system. And the man pages or don't subsequent installs check those? And /etc/perl.conf or whatever configs it uses? > Compile your own perl, > making sure to tell it to install itself in the right place, That's the big trick. Where is the accepted "right place" (ie where subsequent package installs will be correctly placed)? > otherwise it > will end up in /usr/local somewhere. But /usr/local *is* the right place for foreign utilities. It's certainly where I would expect to find Perl. Are you suggesting I should put it somewhere else? If so, where is a good place? > If it does end up there, you can always > symlink /usr/bin/perl to /usr/local/bin/perl and it shouldn't matter. This > way all your RPM will THINK perl is there, and indeed a WORKING perl really > WILL be there... Yep, that's what I would normally expect to do if something went looking for Perl in /usr/bin and didn't find it. > Once you do that you will no doubt need to reinstall Apache because your > mod_perl won't work anymore, as it is linked to lib_perl. OK, no problem there. > You can do a source > RPM build of Apache, that SHOULD work, No, that apparently doesn't work with AxKit (RH9 installs Apache2). I used fresh sources of the older version, and mod_perl symbiosed with Apache and they rebuilt themselves OK last time. > just make sure the spec file tells it > to build mod_perl (or else you can use apxs to rebuild mod_perl afterwards, I never got apxs to work, anywhere. > Honestly, RedHat seems determined to make perl unworkeable and for that reason > I've abandoned their distros entirely. They have become a Python shop. <grin/> No bad thing, IMHO :-) > As far as releases of perl go, stick with 5.8.0 (I have no idea what the > subnumbers signify except those are RPM specific, 5.8.0 is a specific release > of perl). The only bug with it is that it assumes files are UTF-8 in some > circumstances, which I guess has been a problem for a few people. Right. But nice people have posted fixes for this. > AxKit > certainly seems to work well with it. I did add 'encoding="utf8"' to a lot of > my XSLT stylesheet XML decilarations to fix some odd characters appearing in > output, but I am not sure what caused that, newer perl or other issues. XML and XSLT I can handle. > Hope that helps. Hugely, very many thanks. ///Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
