Installing Switch.pm in Active perl on windows 10 - perl

I'm trying to get a Perl script running on Windows 10 with Active Perl 5.28.1. It currently runs on windows 7 with Active Perl 5.8.8. When I try to run it I get:
Can't locate Switch.pm in #INC (you may need to install the Switch module) (#INC contains: C:\Perl\lib C:/Perl64/site/lib C:/Perl64/lib) at fds_propagator_with_collision_ephem.pl line 108.
So I tried to install Switch.pm. I started cpan and then did install Switch.pm
I got:
C:\Users\rdirosar>cpan
Loading internal logger. Log::Log4perl recommended for better logging
cpan shell -- CPAN exploration and modules installation (v2.20)
Enter 'h' for help.
cpan> install Switch.pm
Reading 'C:\Perl64\cpan\sources\authors\01mailrc.txt.gz'
Use of uninitialized value $command in concatenation (.) or string at C:\Perl64\lib/CPAN/Tarzip.pm line 163, <IN> line 1.
'-qdt' is not recognized as an internal or external command,
operable program or batch file.
............................................................................DONE
Reading 'C:\Perl64\cpan\sources\modules\02packages.details.txt.gz'
Use of uninitialized value $command in concatenation (.) or string at C:\Perl64\lib/CPAN/Tarzip.pm line 163.
'-qdt' is not recognized as an internal or external command,
operable program or batch file.
Warning: Your C:\Perl64\cpan\sources\modules\02packages.details.txt.gz does not contain a Line-Count header.
Please check the validity of the index file by comparing it to more
than one CPAN mirror. I'll continue but problems seem likely to
happen.
Warning: Your C:\Perl64\cpan\sources\modules\02packages.details.txt.gz does not contain a Last-Updated header.
Please check the validity of the index file by comparing it to more
than one CPAN mirror. I'll continue but problems seem likely to
happen.
.Could not split line["┬0\cL²\cU\c?└'≈\cCé"]
Could not split line["c▐X'Γπ"├█\cP\cE?▀&δ┌╠5α%â╛mτl∞Bô⌠ñg▒R\cI¥\cT\cP╘≈\cX."]
Could not split line["V╟\c]\$≈»1"]
Could not split line["a\cVk\cQ0y│ôδNj+╒1<c;¼òPb╪Zà⌠∞\cBl≥┤h\cRU\cPFÄ┴▄4û\cIƒ\#⌐╜─b*QZ\$lEX╞╔■î>∩îÅ=\cF┬N;│¼-\cZu¿fÆh\eD"]
Giving up parsing your C:\Perl64\cpan\sources\modules\02packages.details.txt.gz, too many errorsReading 'C:\Perl64\cpan\sources\authors\01mailrc.txt.gz'
Use of uninitialized value $command in concatenation (.) or string at C:\Perl64\lib/CPAN/Tarzip.pm line 163.
'-qdt' is not recognized as an internal or external command,
operable program or batch file.
............................................................................DONE
Reading 'C:\Perl64\cpan\sources\modules\02packages.details.txt.gz'
Use of uninitialized value $command in concatenation (.) or string at C:\Perl64\lib/CPAN/Tarzip.pm line 163.
'-qdt' is not recognized as an internal or external command,
operable program or batch file.
Warning: Your C:\Perl64\cpan\sources\modules\02packages.details.txt.gz does not contain a Line-Count header.
Please check the validity of the index file by comparing it to more
than one CPAN mirror. I'll continue but problems seem likely to happen.
Warning: Your C:\Perl64\cpan\sources\modules\02packages.details.txt.gz does not contain a Last-Updated header.
Please check the validity of the index file by comparing it to more
than one CPAN mirror. I'll continue but problems seem likely to
happen.
.Could not split line["┬0\cL²\cU\c?└'≈\cCé"]
Could not split line["c▐X'Γπ"├█\cP\cE?▀&δ┌╠5α%â╛mτl∞Bô⌠ñg▒R\cI¥\cT\cP╘≈\cX."]
Could not split line["V╟\c]\$≈»1"]
Could not split line["a\cVk\cQ0y│ôδNj+╒1<c;¼òPb╪Zà⌠∞\cBl≥┤h\cRU\cPFÄ┴▄4û\cIƒ\#⌐╜─b*QZ\$lEX╞╔■î>∩îÅ=\cF┬N;│¼-\cZu¿fÆh\eD"]
Giving up parsing your C:\Perl64\cpan\sources\modules\02packages.details.txt.gz, too many errorsLockfile removed.
C:\Users\rdirosar>
I tried deleting the files in:
C:\Perl64\cpan\sources\authors and C:\Perl64\cpan\sources\modules\
That had no effect, if there are files in the directories they are updated
as needed.
What am I doing wrong?
Robert
note: I found I needed to add some cr/lf to the text, otherwise I would get a error message about code not being formated correctly.

According to https://www.activestate.com/blog/goodbye-ppm-hello-state-tool/ ActivePerl 5.28 has removed the old PPM interactive GUI module installation tool in favor of the new https://platform.activestate.com/ website where you log in, pick modules, builds, waits and finally downloads your own custom runtime as one big .exe or .msi file (on windows anyways).
This installation file includes ActivePerl 5.28 and the modules you picked.
In my test on Windows 10 the Switch module was installed without trouble like this.
Other alternatives might be:
Perl 5.26 where PPM a is still available I think, find it at activestate.com
use the CPAN command from 5.28, but for many if not most modules you need make or dmake. The latter is perhaps easiest available through http://www.mingw.org/
Use WSL - windows subsystem for linux. There apt or yum or similar command for your flavour of linux are available. Easy and dependable way to install Perl modules. In my experience. But this isn't ActivePerl, it's barely Windows, it's mostly Gnu/Linux
Strawberry-Perl for Windows
Switch seems to be (judging by a very quick glance now) just a pure perl module that does not depend on other non-core modules. So you can just download the file from https://fastapi.metacpan.org/source/CHORNY/Switch-2.17/Switch.pm and place it in one of the folders output from perl -le'print for #INC' and make sure the file is readable by the system user.

Related

Cygwin usr/bin/perl: bad interpreter : Permission denied

Hello I'm trying to run a perl script on a Windows 64 bit. I'm getting the error like this :
/usr/bin/perl : bad interpreter : Permission denied
I have my perl script on my windows 64 bit C:\test\perlscripts\testperl.pl.
You probably saved the Perl script with DOS style line endings. The shell is looking for a file called /usr/bin/perl<CR>.
Save your files with Unix-style line endings. My .vimrc which I use with my natively compiled vim and gvim has:
set fileformat=unix
set fileformats=unix,dos
Check your editor's settings for the appropriate options.
To fix line endings in a particular file, use $ dos2unix filename.
You may not install Perl in default cygwin64 package. Please ensure that you have Perl at /usr/bin/perl.exe.
If it is not there, run setup-x86_64.exe again and select Perl interpreter.

CGI Script not responding through Wamp

I have configure wamp for cgi scripts correctly but it is not running following code and giving following server error on executing.
Bad file descriptor: don't know how to spawn child process:
C:/wamp/www/New folder/hello.cgi, referer: http://localhost/New%20folder/
My active perl is installed on C:/wamp/www/perl
here is code:
#!C:\wamp\bin\perl.exe -w
print "Hello World.\n";
Windows does not pay attention to #! lines. You need to make sure that your file extension (.cgi in your case, or .pl more commonly) is associated with your perl executable in the registry.
More info:
There are two ways to run a perl program/script, one is to execute perl directly with the file name of the main program/script as a parameter:
C:\wamp\bin\perl.exe mydir\myprog.pl
Don't ever do this in the cgi directory of your web server.
The other way to execute a program is to just name the file to be run and depend on the OS's built in method to find the right program to run it.
mydir\myprog.pl
On a *nix OS, the 1st two bytes of the file are analyzed to determine what to do with it, if those two bytes are the equivalent of the ASCII string #! then the file is treated as text, & the rest of the 1st line is read with the expectation that it will contain the path to the file's interpreter.
On a Windows OS, the file extension is used to search the registry for the path to the interpreter associated with that file type.

Running Perl Script as CGI Script vs from cmd line

I am trying to run a Perl script as a CGI script. When I run the perl script from cmd line, it runs perfectly well, but it shows the following error when I run it from my browser.
Storable object version 1.012 does not match $Storable::VERSION 1.010 at
C:/Perl/lib/DynaLoader.pm line 225.
Compilation failed in require at C:/Perl/site/lib/AsiaXMLUtils.pm line 20.
BEGIN failed--compilation aborted at C:/Perl/site/lib/AsiaXMLUtils.pm line 20
The perl script concerned has basically been designed to queue some job to a remote software.
In case it rings a bell, Line 20 in the mentioned file is :
use Storable qw(&retrieve &store);
Here are the things I have done :
I have checked the following pages on how to troubleshoot your CGI
script but haven't got around the problem.
I have checked that the perl versions are the same for my PC as well
that used for the software I am sending the script too. I guess had
that been a problem, I wouldn't have been able to run the script
from the commnad line either.
I have run a simple Perl CGI (hello world) script using the same basic html code, so I guess that means I am not putting the cgi files (or accessing them) at the wrong places.
I am running a deadline for finishing this task, and thought should ask what approach I should take to solve such a problem. I am new to Perl. Any cues to what I should read to get around the problem will be greatly appreciated. I cannot share the code anyways, since much of it is proprietary.
Storable is an XS module, which means that it has both C code in Storable.dll (or Storable.so on Unix) and Perl code in Storable.pm. That error indicates that the version of Storable.dll ("Storable object version 1.012") does not match Storable.pm ("$Storable::VERSION 1.010"). If you can run the script from the command line, that means that your webserver is either using a different version of Perl, or #INC is different, or possibly you have an extra Storable.dll in your webserver's directory.
Try to use nstore instead of store. This way, your file will be crossplatform.
Also, try to reinstall the Store module.
Here is how I was able to solve the issue, which btw wouldn't have been possible without the valuable inputs of Miguel Prz and cjm.
Regarding the Storable Module : After reading both the answers, I noticed that my pc had two versions of
Perl. I removed one of them. This got me around the "Storable object
version 1.012 does not match $Storable::VERSION" error. Sounds pretty lame, I know. But I thought I should let you know anyways. But then
I ran into another set of problems. This :
Can't locate
AJE/Constants.pm in #INC (#INC contains: C:/Perl/lib
C:/Perl/site/lib .)
From comparing with the #INC of the perl environment from the
command line (for which I found this SO post very useful), I
noticed that the #INC that my web server was using (consisting of only 2 directories as shown above) did not include
many of the directories in the #INC of the command line perl environment. This is where cjm's words came back to me! I then used use lib to add those files in my
perl script and that solved the problem!
Thank you for all the help!

How to set the cross platform interpreter path?

I would like my scripts works on Windows and UNIX system, so I want some code as blew(just a sample, not work)
if $^O eq 'MSWin32' {
#!/c:/perl/bin/perl.exe
}
else { / non-windows system
#!/usr/local/bin/perl
}
is there any way to do this in perl? it seems the #! line must be the first line of a perl script, so this is impossible?
The shebang (#!/path/to/interpreter) is only used on unix-like systems. And it has to be the first line. On Windows systems, the shebang is not used, instead file ending associations may be used: you can associate the .pl file ending with the perl interpreter.
Command line switches in the shebang will be interpreted by the perl interpreter, regardless of platform.
A safe way to launch perl scripts on all platforms is to actually use the perl command. It will be available in case of an successfull Perl installation. E.g. perl myscript.pl instead of ./myscript.pl. The second options requires that the file is set as "executable" on *nix systems.
#! must be the first two characters of the file, because that's where the kernel looks for them when it tries to launch your file. They're part of a directive for the OS (called the shebang line), and the OS knows nothing about Perl.
If you use a standard Perl installer (such as ExtUtils::MakeMaker) to installer your script, just use #!perl and the installer will adjust any existing #! line for your system.
It's not possible. The "#!" is looked at by the exec*() family of Unix functions, to determine how to run the file. So you can't do any scripting there.
It's not all that useful anyway, since the Windows command prompt (or CreateProc() function, but I'm not sure whether that can be used to launch a batch file) doesn't look for the #!.

How can I install CPAN modules locally without root access (DynaLoader.pm line 229 error)?

Doesn't work with other modules, but to give an example. I installed Text::CSV_XS with a CPAN setting:
'makepl_arg' => q[PREFIX=~/lib],
When I try running a test.pl script:
$ perl test.pl
#!/usr/bin/perl
use lib "/homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi";
use Text::CSV_XS;
print "test";
I get
Can't load '/homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Text/CSV_XS/CSV_XS.so' for module Text::CSV_XS: /homes/foobar/lib/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Text/CSV_XS/CSV_XS.so: cannot open shared object file: No such file or directory at /www/common/perl/lib/5.8.2/i686-linux/DynaLoader.pm line 229.
at test.pl line 6
Compilation failed in require at test.pl line 6.
BEGIN failed--compilation aborted at test.pl line 6.
I traced the error back to DynaLoader.pm it happens at this line:
# Many dynamic extension loading problems will appear to come from
# this section of code: XYZ failed at line 123 of DynaLoader.pm.
# Often these errors are actually occurring in the initialisation
# C code of the extension XS file. Perl reports the error as being
# in this perl code simply because this was the last perl code
# it executed.
my $libref = dl_load_file($file, $module->dl_load_flags) or
croak("Can't load '$file' for module $module: ".dl_error());
CSV_XS.so exists in the above directory
When you installed the module, did you watch the output? Where did it say it installed the module? Look in lib. Do you see the next directory you expect?
Look in ~/lib to see where eveything ended up to verify that you have the right directory name in your use lib statement:
% find ~/lib -name CSV_XS.so
Once you see where it is installed, use that directory name in your use lib (or PERL5LIB or whatever).
I expect you have a lib/lib in there somehow. The PREFIX is just the, well, prefix, and the installer appends other directory portions to that base path. That includes lib, man, bin, etc.
Personally I would suggest to use local::lib. :)
Try this instead:
'makepl_arg' => q[PREFIX=~/]
PREFIX sets the base for all the directories you will be installing into (bin, lib, and so forth.)
You may also be running into shell expansion problems with your '~'. You can try to expand it yourself:
'makepl_arg' => q[PREFIX=/home/users/foobar]
It would also be helpful if you included the commands you used to get the error you are asking about.
It looks from the error message ("at /www/common ...") that your script is a CGI or mod_perl script. The web server is probably not running as the user 'foo', under whose home directory you've installed the module - that could result in the web server being unable to read that directory.
It may also be running in a "chroot jail", which would mean that the directory in which you've installed the module may not be visible to the script.
In other words, just because you can see the module, does not mean that the web server, and therefore your script, can do so. You should check the relevant file permissions, and if the server is chrooted, whether your module directory is mounted within the virtual file system.
Does the file in question (CSV_XS.so) exist?
Does it exist at the listed location?
If you do:
set |grep PERL
What is the output?
Have you successfully installed other local perl modules?
I strongly suggest installing your own perl in your own home directory, if you have space. Then you can keep everything under your control and keep your own module set, as well as escaping if the admins are keeping you on an older version of perl. (Not to mention preserving yourself if they upgrade some day and leave out all the modules you are relying on.)