We have perl version 5.8.4 installed on our servers. I am trying to invoke a HTTP URL from within the perl script and based on the output that the HTTP URL returns I have a logic to be executed.
I am very new to perl and am looking for help to achieve this. The Cpan and other modules seem to be unavailable with the current version we have.
Please let me know how we could achieve this.
Thanks,
Sachin
Take a look at LWP and LWP::simple.
Even older versions of perl will have support for this library, although you may have to install it via cpan.
We have perl version 5.8.4 installed on our servers
Then that should be the first thing that you fix. 5.8.4 is ten years old. It is completely unsupported.
The Cpan and other modules seem to be unavailable with the current version we have.
No. CPAN works fine with versions of Perl back far earlier than 5.8.4. If you are having a problem using them that is a local problem that you should work on getting fixed. Good Perl programming is a case of wiring together the correct CPAN modules. If you can't install CPAN modules then you are missing most of the power of Perl.
The correct answer to your problem is to install LWP::Simple and use its get function. If you don't want to do that, then reading the source code for that module will show you the lower level code that you would need to write.
Related
This question already has answers here:
Which cpan installer is the right one? (CPAN.pm/CPANPLUS/cpanminus)
(5 answers)
Closed 4 years ago.
What is the difference between the cpan/cpanm and cpm commands?
I'm perl-begginer. What I can use: cpan/cpanm or cpm? Thanks.
These are all different programs that essentially do the same thing. They install modules from the CPAN (Comprehensive Perl Archive Network) to your computer.
cpan is the utility that Perl brings to install modules. It can be used as a shell or a simple command line utility. It uses the module CPAN under the hood.
cpanp is the utility to use the CPANPLUS module. It also has an integrated shell, and in general is a bit faster than the classic cpan tool.
cpanm is a faster, less fully-featured CPAN client that comes with the App::cpanminus distribution. It does not have a shell, and is the de-facto standard today, as most people recommend using it. It's fast, easy to use and usually you don't have to care about what is happening behind the scenes. There's also the handy cpanm-reporter in a separate distribution, that you can use to send test reports of your installations to cpantesters.org, which will then show up on metaCPAN and in other places, so other people know whether a certain dist will work with their OS and Perl version.
cpm is yet another client to install modules from CPAN. It's relatively new and claims to be very fast. It uses Menlo under the hood, which is the new backend the author of cpanm is working on to replace the internals of that one. It does not have a shell.
If all you want to do is install modules, it really doesn't matter what you use. cpan will always be available, but once you're used to cpanm it starts feeling a bit tedious.
I suggest you use whatever you feel comfortable with.
Is there a command line switch or any other easy way that I can check the compatibility of my module with different versions of perl? I understand that if I put use 5.6.1; at the top of a script, the script will have any features later than 5.6.1 disabled. But if I have a module which uses several other modules and so on, I need a quicker way to check what minimum version of Perl to require in my Makefile.PL or Build.PL.
Run your module against Perl::MinimumVersion.
use v5.6.1 and similar will primarily raise a compile-time error if the version of Perl in use is older than that specified. In addition, the corresponding feature bundle is enabled, and if the version is v5.11 or higher, the strict pragma is enabled as well.
use v5.6.1 will not make Perl v5.8 behave like v5.6.1, and there is no way of achieving this. Even in later versions it is only features that can be controlled using the feature pragma that are adjusted to a given version.
To test your module you will have to install each different version of Perl and test it separately
You can just install different versions of perl and test against those. I install them by hand in different locations but if you want to automate that, use perlbrew.
There might be scripts or strategies that try to find the minimum version of perl needed, but everything i tried several years ago to obtain and aggregate the minimum perl version i found clunky and unreliable. Which of course doesn't mean, that it doesn't exist or can't be done, but just that i couldn't find it.
I'm trying to install WWW::Mechanize; but of course, something had to go wrong. I purchased a VPS, and whenever I load up CPAN (AKA The quick way), it says I'm missing modules. Such as... HTTP, LWP, Test, HTML, LOADS of things that I thought would come standard with a perl installation. I tried doing a few of them one by one, but they all fell like a stack of dominos. I don't even think my perl installation has most of the core modules.
For example... Trying to install LWP:
HTTP::Status
HTTP::Negotiate
HTML::Entities
HTTP::Daemon
HTML::HeadParser
HTTP::Cookies
HTTP::Request::Common
HTTP::Response
HTTP::Request
Says I need those modules; and then when I install those, it's basically an endless cycle with errors being returned and failed tests.
Installation of HTTP::Message:
IO::Uncompress::Inflate
IO::Uncompress::Gunzip
IO::Compress::Gzip
IO::Uncompress::RawInflate
Compress::Raw::Zlib
IO::Compress::Deflate
HTML::Parser
IO::Compress::Bzip2
IO::Uncompress::Bunzip2
TL;DR: Can't install standard modules, returns fail. Doesn't even have extremely common modules.
Keeping the core distribution as small and light as possible is beneficial, as Perl is used in many situations with varying amounts of space.
You haven't mentioned any modules that are actually core, nor your Perl version, nor your OS version/distribution (which some I have understood don't actually distribute a full Perl installation themselves). If you find out for sure that this is actually the case, it's an issue with your distribution, and you should bring it up with them.
You also haven't actually asked a question anywhere.
Just install what you need, when you need it.
Edited for your edit: The first block of modules you listed is not core. The second block is partially core since 5.9.4, and partially since 5.10.1.
IO::Uncompress::Inflate was first released with perl 5.009004
IO::Uncompress::Gunzip was first released with perl 5.009004
IO::Compress::Gzip was first released with perl 5.009004
IO::Uncompress::RawInflate was first released with perl 5.009004
Compress::Raw::Zlib was first released with perl 5.009004
IO::Compress::Deflate was first released with perl 5.009004
IO::Compress::Bzip2 was first released with perl 5.010001
IO::Uncompress::Bunzip2 was first released with perl 5.010001
You still haven't mentioned an OS distribution/version, a Perl version, or provided the error messages you receive. The cpan command-line or commands you're using would help, too.
What Linux distribution? If Debian/Ubuntu you will want to install the build-essential package via aptitude for make and friends. I'm sure RPM based distros would have similar packages available as well.
What are the actual errors you are getting? Have you tried installing a small no non-core dependencies distribution like Try::Tiny manually to see what fails?
cpan fails with this weird error as follows
Error: Unable to locate installed Perl libraries or Perl source code.
It is recommended that you install perl in a standard location before
building extensions. Some precompiled versions of perl do not contain
these header files, so you cannot build extensions. In such a case,
please build and install your perl from a fresh perl distribution. It
usually solves this kind of problem.
(You get this message, because MakeMaker could not find "D:\fbl_esc_bcd_tb\tools\perl\lib\CORE\perl.h")
Running make test
Make had some problems, maybe interrupted? Won't test
Running make install
Make had some problems, maybe interrupted? Won't install
Problem is I can't install new active perl versions in this environment and the tool I want to coverage on does not run outside this environment.
Short answer: The ActiveState PPM repository has a precompiled version of Devel::Cover you should be able to install.
Long answer: That's not a normal message from MakeMaker so I'm willing to guess its an ActiveState addition, but its probably true. The problem is exactly what the error message says; your distribution is missing some important files, specifically the C header files for Perl, so it cannot compile C code necessary for modules like Devel::Cover. This is often the result of an overzealous sysadmin or packager looking to save a few dozen K of disk space. You could probably take the header files from the 5.8.7 source, copy them into the CORE directory and it will probably work. It won't make anything worse.
I agree with Evan that, assuming this is a Windows machine, you should switch to Strawberry Perl which plays much better with the rest of the Perl community than ActivePerl.
Otherwise, ActiveState is a commercial company and they have paid Perl support. Give them a ring.
Active Perl does not use CPAN. If you want to use CPAN use Strawberry Perl. Active Perl uses binary distribution through its ppm system. There are a few third party repos for it if the official one doesn't have Devel::Cover -- though the official probably has Devel::Cover.
Most people these days are moving to Strawberry and away from AS. In my opinion, it is far more stable and CPAN-friendly, and surely less proprietary. Also, expect to be able to get stable versions of most everything - AS has been known to lag years in many occasions in the official repos. strawberry also comes with its own compiler and build environment so you can even get ::XS versions working with ease.
I want to use Apple's or RedHat's built-in Apache but I want to use Perl 5.10 and mod_perl. What's the least intrusive way to accomplish this? I want the advantage of free security patching for the vendor's Apache, dav, php, etc., but I care a lot about which version of Perl I use and what's in my #INC path. I don't mind compiling my own mod_perl.
Build your version of Perl 5.10 following any special instructions from the mod_perl documentation. Tell Perl configurator to install in some non-standard place, like /usr/local/perl/5.10.0
Use the instructions to build a shared library (or dynamic, or .so) mod_perl against your distribution's Apache, but make sure you run the Makefile.PL using your version of perl:
/usr/local/perl/5.10.0/bin/perl Makefile.PL APXS=/usr/bin/apxs
Install and configure mod_perl like normal.
It may be helpful, after step one, to change your path so you don't accidentially get confused about which version of Perl you're using:
export PATH=/usr/local/perl/5.10.0/bin:$PATH
You'll want to look into mod_so
I've done this before. It wasn't pretty, but it worked, especially since vendor perl's are usually 2-3 years old.
I started with making my own perl RPM that installed perl into a different location, like /opt/. This was pretty straight forward. I mostly started with this because I didn't want the system utilities that used perl to break when I upgraded/installed new modules. I had to modify all my scripts to specify #!/opt/bin/perl at the top and sometimes I even played with the path to make sure my perl came first.
Next, I grabbed a mod_perl source RPM and modified it to use my /opt/bin/perl instead of /usr/bin/perl. I don't have access to the changes I made, since it was at a different gig. It took me a bit of playing around to get it.
It did work, but I'm not an RPM wizard, so dependency checking didn't work out so well. For example, I could uninstall my custom RPM and break everything. It wasn't a big deal for me, so I moved on.
I was also mixing RPM's with CPAN installs of modules (did I mention we built our own custom CPAN mirror with our own code?). This was a bit fragile too. Again, I didn't have the resources (ie, time) to figure out how to bend cpan2rpm to use my perl and not cause RPM conflicts.
If I had it all to do again, I would make a custom 5.10 perl RPM and just replace the system perl. Then I would use cpan2rpm to create the RPM packages I needed for my software and compile my own mod_perl RPM.