Hi o2bwise,

The first thing you want to do is read through $ perldoc perlmodinstall (http://perldoc.perl.org/perlmodinstall.html).

Next, you'll want to learn about using the CPAN console, which takes care of a lot of the confusing parts of installing modules.

For the particular module you are installing, the command would be: $ perl -MCPAN -e 'install libwww-perl'.

Also, its good that you've been given a newer perl as the default one you have is very old, but you are adding a layer of complexity here.

I suggest putting the new perl in your environment's path so you and all programs that you run that use perl use the new one. You said you found version 5.8.5 but you didnt say exactly where it was, but given it is installed in /opt/perl58/bin, you'd add that path to your environment path.

I also recommend NOT removing the old perl as pieces of your system probably depend on it.

Hope this helps getting you started, and if you have more specific questions dont hesitate :-)

Thanks all of you. I'll hammer through those doc's.

Related comments...

One.
Regarding version of perl. I haven't run a perl program yet, what I meant by "version of perl" is that I downloaded the mod in a path associated with perl 5.8.5.

Two.
And related to One. It seems strange to me that @INC would not be influenced by the perl path I am using and I am wondering if anyone knows how @INC is defined. My guess is that it is defined according to the user. If so, it would seem to follow that I could have a zillion versions of perl at my disposal, but @INC is not influenced by the version I am using. Again, in this case, I haven't written a perl program with a shebang line, the version of perl I refer to is that version associated with where I downloaded the mod.

Three.
Just a note that I tried to download the CPAN mod awhile back. It required so many other mods and my attempt was unsuccesful. I don't recall the reason it was unsuccesful. Maybe I'll give that another go.

Thanks!

Tony

Now I am remembering why I had such a hard time with the CPAN mod. It's a work server and it has proxy's set up. Anyway, I identified the proxy servers, but I got the following error:



You have no /export/home/vz291w/.cpan/sources/MIRRORED.BY
  I'm trying to fetch one
CPAN: Net::FTP loaded ok
Fetching with Net::FTP:
  ftp://ftp.perl.org/pub/CPAN/MIRRORED.BY
Fetching with Net::FTP
  ftp://ftp.perl.org/pub/CPAN/MIRRORED.BY.gz
Issuing "/usr/bin/ftp -n"
ftp.perl.org: unknown host or invalid literal address
Not connected.
Local directory now /export/home/vz291w/.cpan/sources
Not connected.
Not connected.
Not connected.
Not connected.
Not connected.
Bad luck... Still failed!
Can't access URL ftp://ftp.perl.org/pub/CPAN/MIRRORED.BY.
[download]



Even if I try it interactively:



ftp ftp.perl.org
ftp.perl.org: unknown host or invalid literal address
[download]



Also, I am ~99% sure the server will not allow ftp anyway as for other applications, I have had to use sftp.

Anyway, any recommendations? Is hope for using CPAN.pm a bit unrealistic? If so, what is my MO? My guess is to keep installing mods manually, note every failure for lack of other needed mods, and install all of those as well.

Does that sound about right?

Thanks again...

Tony

Installing with CPAN is probably the safest way to install modules.

The mighty fine Life with CPAN document is well worth a read as well.

If so, you'll need to make sure that you are running that perl instead of your older system perl. Even if you change your PATH so that you pick up your newer perl, you may find that some scripts you have start with '#!/usr/bin/perl' which will use the system perl. If you start your scripts with '#!/usr/bin/env perl' then this will check your PATH and find the newer one.

Otherwise, follow the advice in the other posts and use CPAN to install modules. It will put them in the correct place for the version of perl you use to run CPAN.

Of course if one doesn't have sufficient control over what environment your CGI programs are run then using env may just lead to more confusion and delay(</Sir Topham Hatt>). Things exec'd by the web server may not necessarily have anything resembling what your interactive shell gets as a PATH.