mpolo has asked for the wisdom of the Perl Monks concerning the following question:

I am presently stuck developing on a pretty old machine in our Intranet. It's got RH Linux 6.2, so is running Perl 5.003 and a rather old (5.36) version of LWP.

This version of LWP chokes on the normal $ua->proxy('http','http://username:password@proxy:port/') This version of LWP also lacks the proxy_authentication method that I found by searching Perlmonks.

Installing modern modules is something of a hit-and-miss on this computer, due to the older libraries and program versions. In particular, "use warnings" and "our" are no-no's, and require lots of wild editing of the module files.

How can I make this work with the old LWP, or how new an LWP I would need to install to get this functionality? Would the newest LWP likely install on such a machine with just removing all the "use warnings" and removing the "our"s (probably nuking "use strict" in the process -- not the nicest thing in the world to have to do)? Unfortunately, the server I am programming on is a production machine, and an upgrade to a modern OS and Perl would break things that I would rather not have to fix (like a big PHP site -- ick), and is remote to me. This is the only use of LWP on the server, so I can freely mess with that...

Replies are listed 'Best First'.
Re: Ancient LWP and proxies
by cees (Curate) on Nov 30, 2003 at 22:29 UTC

    A couple options come to mind:

    1. There is probably no need to go to the absolute latest version, so look through the archived versions of LWP and see when the proxy auth code was added (the Changes file should help). Perhaps there exists an older version that still works properly with your version of perl.
    2. Or install a copy of perl in your homedir and use it instead of the system perl.
    3. Or like you mention, install a new version of LWP in a nonstandard dir and throw a 'use lib qw(/path/to/lwpdir/);'. As for the changes that you are likely to need to make, what you mention sounds OK, but you shouldn't need to turn off strict. Just change all 'our $globalvar' vars to 'use vars qw($globalvar);'. 'our' and 'use vars' are not identical, but should be close enough.
    4. Or if none of those are workable, then ditch LWP and launch an external program like 'wget' instead. Not ideal or efficient for that matter, but it should work.
[reply]
      Thanks for all of the replies. It turned out that the latest version of LWP installed without a whole lot of effort. I only had to remove the "require 5.005" line from the Makefile.PL and comment out the live testing (since I can only access by proxy on that machine, and the live testing tries to open a socket to www.google.com, which takes an awful long time to time out, for one reason or another -- more than the 10 in the source, I think). After getting a few more prerequisite modules (and deciding not to mess with my working libnet to get FTP to work in LWP), all the brilliant (ha!) scripts I had prepared worked just fine.
[reply]
Re: Ancient LWP and proxies
by Roger (Parson) on Nov 30, 2003 at 22:44 UTC
    I can see two strategies that might work here (although none I consider as particularly appealing.)

    Strategy 1
    Assuming that your old perl was installed under /usr/bin, /usr/lib/perl. Install a modern version of Perl, 5.8.2, say, under a different directory /usr/local/bin, /usr/local/lib/perl. So that you have two different perl environments on the same machine.

    Then install the latest LWP modules under the new perl environment. Although that your kernel is old, but I think the latest Perl should still compile and work gracefully.

    Strategy 2
    The current version of LWP on CPAN is version 5.76, which requires perl 5.005 as minimum. You could download the source package and fudge the perl sources. Remove the require 5.005 constraint, run the test cases, and fix whatever error that shows up.



    In a long run, you are much better off if you upgrade to later version of Perl, with modern libraries. Otherwise you will be missing a lot of new features and upgrades. Personally I would favour strategy 1, just give it a go and see, you never ever know if you never ever try.

[reply]
[d/l]
      While I agree installing multiple versions of Perl is a good thing, I don't agree with your naming scheme. /usr/local/bin/perl for 5.8.2 next to /usr/bin/perl for the older version seems like a good idea, but it doesn't scale. Perhaps after a year you need 5.10, of 5.8.6; where are you going to place that? I would suggest something like: /opt/perl/5.005_03, /opt/perl/5.6.1, /opt/perl/5.8.2, etc. Just a separate dir for each versions of Perl you have in use, and all a subdir from a common dir.

      Alternatively, if you have a machine that has just a few applications installed, you could make Perl part of the application itself. Say, the application installs itself in /opt/my_app, just install the required version of Perl somewhere below /opt/my_app; this gives the application full control over which version of Perl is being used. I've succesfully used that technique myself in the past (for both Perl and Java), and it works like a charm.

      Abigail

[reply]
          ...make Perl part of the application itself. Say, the application installs itself in /opt/my_app, just install the required version of Perl somewhere below /opt/my_app; this gives the application full control over which version of Perl is being used.

        That's an excellent idea.

[reply]

Back to Seekers of Perl Wisdom