On a certain system, I am running a perl script and it's failing by saying
Can't locate List/Util.pm in #INC (#INC contains: <Some-Path>/ActiveState/perl/lib <Some-Path>/ActiveState/perl/site/lib .) at <Some-Other-Path>\searchCobolPgms.ps line 7.
Now the strange part is that before deploying the code into the failing system, I ran it on my laptop and it just ran fine. The difference in both the system is, in my laptop I am using Cygwin and perl is bundled with it and the said failing system has ActiveState perl.
<Some-Path>perl -v
This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2001, Larry Wall
Binary build 635 provided by ActiveState Corp. http://www.ActiveState.com
Built 15:34:21 Feb 4 2003
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
I then searched for Util under the lib of cygwin and it was present under i686-cygwin
c:\cygwin\lib\perl5\5.10>find . -name Util.pm
./CGI/Util.pm
./i686-cygwin/Hash/Util.pm
./i686-cygwin/List/Util.pm
./i686-cygwin/Scalar/Util.pm
So now I am confused. Isn;t List::Util part of the standard perl distribution?
The Reason for my confusion
List/Util.pm is present under i686-cygwin
ActiveSync Installation was not having List/Util.pm
List::Util was only added to core in 5.7 (a development version) and the first stable release of perl containing List::Util was 5.8.0. So, while it is in the perl 5.10 distro you have installed under cygwin, the perl 5.6.1 ActiveState executable you called does not have it. You should update the ActiveState perl to at least 5.8.0, and then it will have the module you need.
Here is a link to find all versions of perl that contain a core module: http://perlpunks.de/corelist/version?module=List%3A%3AUtil
When I check corelist I get:
corelist List::Util
List::Util was first released with perl v5.7.3
Your perl version seems to be 5.6.1, in which case List::Util would not be part of the core installation.
Judging by the path c:\cygwin\lib\perl5\5.10, it seems your cygwin version is at least 5.10, but as you will note, the cygwin path is not in the #INC of your other perl version. They are most likely separate installations, and therefore they do not share libraries.
Update your ActiveState perl, and all should be well.
Related
I am eager to learn Raku(Perl 6) and its syntax.
I already have Perl 5 installed in my Ubuntu machine.
vinod#ubuntu-s-1vcpu-1gb-nyc1-01:~$ perl -v
This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux-gnu-thread-multi
(with 67 registered patches, see perl -V for more detail)
Copyright 1987-2017, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
I want to install Raku in the same Ubuntu system. I have couple of questions:
How can I install Raku ?
If I install Raku, will Perl 5.26 will be get wipedout/updated? I want Perl 5.26 in my system because couple of scripts are running in Perl 5.
Can I have 2 versions of Perl in single server ?
Once if I install Raku, how can I run the Raku/Perl 5 code in Ubuntu server? Is it like I should mention use Perl 5.26; at the beginning? By default which version of Perl it will take?
How can I run Raku code?
$ sudo apt-get install rakudo
[ ... stuff happens ... ]
$ perl6 -v
This is Rakudo version 2018.03 built on MoarVM version 2018.03
implementing Perl 6.c.
$ perl -v
This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux-gnu-thread-multi
(with 67 registered patches, see perl -V for more detail)
The Raku compiler is in a package called rakudo. That package includes a program called perl6 which is the actual Raku compiler. The Perl compiler and the Raku compiler are two completely separate programs, so there is no problem having them both installed and running code using either of them. They are as separate as Perl and PHP.
Update: In a (now, bizarrely, deleted) comment, you asked
What was the way to open a vi editor and write a code in that
You do it in exactly the same way as you would do it for any programming language where the code is compiled or interpreted on each execution - Perl, Python, Ruby, bash, they all work the same way.
You can write a text file containing Raku code and run it with perl6 your_file_name.
Or you can put the correct shebang line (which is #!/usr/bin/perl6) at the top of the file and make the file executable with chmod +x your_file_name.
There is a community maintained Repository of the most recent build of Rakudo available here : https://nxadm.github.io/rakudo-pkg/
This is generally updated a few days after each official release and is currently on 2019.07.1
I'm working on a legacy product which uses the Docker perl:5.10-threaded image and ran into an issue trying to debug things when I discovered there are two version of perl - one in /usr/local/bin/perl and one in /usr/bin/perl. In this particular image, they are actually different versions
/usr/local/bin/perl -> 5.10.1
/usr/bin/perl -> 5.20.2
The issue it was causing is that each has a different #INC path.
$ /usr/local/bin/perl -V
[snip]
/usr/local/lib/perl5/5.10.1/x86_64-linux-thread-multi
/usr/local/lib/perl5/5.10.1
/usr/local/lib/perl5/site_perl/5.10.1/x86_64-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.10.1
$ /usr/bin/perl -V
[snip]
/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.20.2
/usr/local/share/perl/5.20.2
/usr/lib/x86_64-linux-gnu/perl5/5.20
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.20
/usr/share/perl/5.20
/usr/local/lib/site_perl
.
The latest versions, like perl:5.30-threaded also have two versions and different #INC paths as well.
/usr/local/bin/perl -> 5.30.0
/usr/bin/perl -> 5.28.1
It turns out my legacy app uses #!/usr/bin/perl, which was very confusing to me when perl foo.pl didn't work the same as foo.pl (it complained about missing libraries).
To add a bit more color, this legacy app also installs a bunch of perl libraries via apt-get. E.g.,
libcpanel-json-xs-perl libxml-libxml-perl libcgi-pm-perl
libtie-ixhash-perl
libswitch-perl libmime-lite-perl liblist-moreutils-perl
libdate-calc-perl libnet-sftp-foreign-perl
libxml-libxslt-perl liburi-escape-xs-perl
libdatetime-perl
These seem to install things accessible by /usr/bin/perl, which is perhaps why the app uses it in the shebang lines.
The other thing this app does is install some cpanm items and then copy them over, so they are accessible to /usr/bin/perl
RUN cpanm XML::XML2JSON
RUN cpanm JSON
RUN cp /usr/local/lib/perl5/site_perl/5.10.1/XML/XML2JSON.pm /usr/lib/x86_64-linux-gnu/perl5/5.20/XML
RUN cp /usr/local/lib/perl5/site_perl/5.10.1/JSON.pm /usr/lib/x86_64-linux-gnu/perl5/5.20
This seems like a hack to me, but I'm new to perl development, so who knows?
All this leads up to my questions:
why are there two version of perl in the Docker images?
are apt-get and cpanm incompatible with each other?
is there a better way to install these perl libs?
Perl is an essential part of many Linux distributions, and has to come pre-installed. The system perl that is used by the operating system is usually installed as /usr/bin/perl. Modules for it are managed through the package manager (e.g. apt) and not via cpan/cpanm. If you were to install modules for the system perl yourself, this might conflict with modules expected by the operating system. Worse, installing the wrong module version could break parts of the OS. Similarly, replacing the system perl is a bad idea. That's why those Docker images install the different perl alongside.
For your apps, you should avoid the system perl. If you want to install extra modules for use with the system perl, consider using local::lib. In some cases you might install dependencies such as C libraries or external tools via apt, but you wouldn't use apt-provided Perl modules.
Unless you are targeting a specific operating system, do not hardcode the #!/usr/bin/perl shebang. Instead, prefer #!/usr/bin/env perl so that the script will use the perl that is first in the PATH. Alternatively, use wrapper scripts to explicitly invoke the correct perl installation. For example:
#!/bin/sh
exec /usr/local/bin/perl -I/path/to/extra/modules /path/to/my/script "$#"
Note that you cannot share modules between different versions of Perl. During installation of XS modules they are compiled for a specific version, and will fail to load with a different Perl version. For your local perl, just install dependencies via cpanm and ignore modules that were installed for the system perl.
I want to use Perl for web development. I have tried to find out how to install it but when I tried to get ActivePerl it wouldn't install on Windows 8. Can anyone tell me how to install Perl on Windows 8? I can go for ActivePerl, Strawberry Perl, or any other Perl release as long as it will work on Windows 8.
As you already know, there are two generally used Perls in the Windows World:
ActivePerl from ActiveState.
Strawberry Perl which is an open source project started by Adam Kennedy -- a big honcho in the Perl community.
What's the big difference between them:
ActiveState Perl was designed to be a Perl solution specifically for Windows (and later both Macs and Linux). ActiveState offers a very nice Perl IDE called Komodo and has excellent Perl support. All you need is some cash. After all, that's how ActiveState makes its money. Of course, you can use EPIC instead of Komodo and get a lot of help from StackOverflow too.
ActiveState comes with the default Win32 modules already installed and also supplies a Perl Package Manager (PPM) instead of using CPAN for installing other CPAN modules. PPM has a nice GUI interface, and its modules have already been precompiled and tested. It also is a bit better than CPAN with dependency tracking. Of course, there might be some CPAN modules not in PPM, and that can be an issue.
Strawberry Perl was started to be more Open Source oriented than ActiveState. By default, Strawberry Perl comes with a Make program and a complete development environment, so that almost all CPAN modules are available and can be installed. This is because Strawberry Perl comes with the complete MinGW package which includes Make and a gcc compiler. The idea was to give Perl people who mainly use Linux and Unix machines a similar feeling solution for Windows.
In reality, both are pretty similar. ActiveState comes with the Win32 modules, but you can install them as needed on Strawberry Perl via CPAN. Strawberry Perl works with CPAN, but ActiveState gives you complete directions for installing the same MinGW environment that Strawberry Perl uses (via their PPM) which allows you to install all CPAN modules that Strawberry Perl can install. ActiveState comes with a GUI Perl Documentation that includes all installed Perl modules, but the perldoc command gives you the same information anyway.
So, if you're more Linux/Unix oriented and want something that feels very similar on Windows, go with Strawberry Perl. If you are using Perl as a Win32 solution, go with ActiveState. And, don't worry about choosing the wrong one. In the end, Strawberry Perl can include all those nice Win32 modules, and ActivePerl can use CPAN.
There is another SO posting that you might find what you're looking for here. A similar posting. In sum, I get the impression that Strawberry Perl would work alright, and so would ActivePerl. I rather liked Strawberry Perl, and it was so long ago that I installed it on my wife's Windows Vista machine that I can't remember why I chose it over ActivePerl, ymmv. CHEERS!
I have installed Strawberry Perl for Windows, "DWIM Perl" from: http://dwimperl.com/.
I would like to use Carp. So I have downloaded Carp-1.25 from CPAN, un-TAR-ed it, and ran nmake.
I get:
Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
to undefined at F:/Dwimperl/perl/lib/ExtUtils/Install.pm line 1208
NMAKE : fatal error U1077: 'F:\Dwimperl\perl\bin\perl.exe' : return code '0x2'
Stop.
Note that it's not a Windows nmake problem, I get a similar error when running make in cygwin.
My system: MS Windows 7.
(By the way, I have been running ActiveState Perl fine, and there, PPM downloads and installs Carp with no problem.
The reason I've switched to Strawberry/DWIM Perl, is that I'd like to run a debugger, and Padre's latest version on ActiveState is 0.86, which is buggy. So I've installed DWIM Perl since I'd like to use Padre 0.92).
Carp is a core module so it be included with your Perl installation. Just try use Carp in your code.
and ran nmake.
why use nmake? DWIMPerl( StrawberryPerl) is not known to come with nmake, generally they come with dmake, and AFAIK, their documentation reflects this
Carp comes with your Perl distribution, it is a core module. corelist (offline version) shows you the standard modules that come with various Perl versions. You'll see that Carp comes with all Perl versions as far back as 5. There's nothing to download. Just use Carp. One of the hard things to understand about Perl for many people is that certain functionality doesn't exist except in modules, but these modules come with Perl anyway. I've seen a lot of people use system cp or system find because they didn't realize that Perl comes with a module to copy files or to search a file in a directory tree. It's in a module that you have to use.
Try using the cpan command to download your modules. The cpan command will search for, download, compile, test, and install any module you need. One of the reasons people use Strawberry Perl over ActivePerl is that, historically, the cpan command worked better on Strawberry Perl than on Active Perl.
I'd like to install a Perl module (in this case, FindBin), but since it is included in the Perl 5.10.1 distribution, cpan wants to install Perl 5.10 for me. Is there a way of installing just the module via cpan?
The only option that I can see is installing directly from source, which seems a bit crude as there is no separate package (for example, Makefile.PL, etc.), just the bare .pm file.
Since this is a small module that only has the one file, it's doable in this case, but what if I wanted to install a much larger package?
EDIT: This is somewhat aside from the original question, but speaks to the general issue of modules being packaged up with Perl distributions: I discovered that the "standalone" FindBin (version 1.49) had a syntactic error, so I retrieved version 1.50 out of the Perl 5.10.1 distribution... However since the module is now listed on CPAN as part of Perl 5.10, I am unable to find the CHANGES file describing what was changed/fixed in this delta. Is it reasonable that I should have to go into the developer repository to pull out this information?)
EDIT 2. Okay, here's a better example. On Perl 5.8.8 I have version 1.04 of Carp. However, I see that Perl 5.10.1 comes packaged with version 1.11. Is there a way of getting CPAN to install the latest version of Carp for me without dragging in all of Perl 5.10.1? I can't even find a link to the Carp module on CPAN except to the perl 5.10.1 installation.
> corelist FindBin
FindBin was first released with perl 5.00307
Which version of Perl do you use that does not include FindBin? If you use at least Perl 5.6.0 (all versions before are considered deprecated), you have no need to install FindBin. If you have anything older, I suggest an upgrade to 5.6.2/5.8.9/5.10.1.
Kurila is not a "standalone" FindBin, it's a dialect of Perl. FindBin is not a dual life and is released only bundled with Perl. You can consider releasing FindBin to CPAN as standalone distribution - it is easy if you used ExtUtils::MakeMaker in past.
Latest useful change of FindBin was on 2007-04-28, related to VMS. Latest useful non-VMS change was on 2006-10-25.
Things you can try include
Dropping FindBin.pm into the same directory as your executable and using use FindBin
Dropping FindBin.pm into your Perl library directory
Using the source code of the module in your script