I've been running a perl script from python successfully for a while. I've just moved everything to a new computer (both are running Windows 10) and I'm running into issues.
When running the script I get the error:
Can't locate DBI.pm in #INC (you may need to install the DBI module) (#INC contains: /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl)
On the first line use DBI;.
I moved to using Perl (command line), selected the folder with the script and ran perl <filename> - same error.
DBI seems to be installed correctly in C:\Strawberry\perl\vendor\lib and that directory is in my #INC when I check via perl -V:
#INC:
C:/Strawberry/perl/site/lib
C:/Strawberry/perl/vendor/lib
C:/Strawberry/perl/lib
I've tried installing DBI again using cpan Module::DBI but I get the error:
Could not expand [Module::DBI]. Check the module name.
I've tried installing it with perl -MCPAN -e "install Bundle::DBI" but it fails with:
Test Summary Report
-------------------
t/original.t (Wstat: 0 Tests: 27 Failed: 1)
Failed test: 26
Files=1, Tests=27, 1 wallclock secs ( 0.05 usr + 0.01 sys = 0.06 CPU)
Result: FAIL
Failed 1/1 test programs. 1/27 subtests failed.
gmake: *** [Makefile:863: test_dynamic] Error 255
NEILB/IO-Tee-0.65.tar.gz
C:\STRAWB~1\c\bin\gmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports NEILB/IO-Tee-0.65.tar.gz
Stopping: 'install' failed for 'IO::Tee'.
I didn't have any issues when setting things up on my previous machine (both times it has just been a vanilla install with no importing of additional modules).
I've tried reinstalling Strawberry a couple of times to no avail. I've tried installing perlbrew and ActivePerl but hit issues with both of those. I've also now exhausted Google for potential solutions.
Any ideas?
Edit:
Following the advice here I have run perl -e "use DBI;" and there is no error message which apparently means DBI is installed correctly?
Edit 2
Ok so I've managed to get things working via Perl (command line) and also via Windows cmd - it took a complete reinstall of MySQL which doesn't really make any sense but anyways. However, I still can't execute the script using Git Bash. I get the same error as always...
[ Update: Bug fixed in IO-Tee 0.66. ]
The failing test assumes that sysread obeys the :crlf layer that's added to file handles in Windows. But it doesn't. This is a bad test, not a problem with the module. As such, since that's the only failing test, you can safely force the installation of the module using the following:
cpan -f IO::Tee
Forcing the installation of a module with failing tests is normally a bad idea because it means you're forcing the installation of a module that's likely broken. But it's ok here because it has been established that the problem is with the test, not the module itself.
I have filed a bug report with a more thorough explanation of the problem and a solution.
Related
I have an issue with a Perl script and the CPAN Twitter module.
I have a script that runs speedtest, and am trying to post the result to Twitter.
I have managed to get my script running manually by running ./speedtest.pl from my user account, however when I try and run it using crontab I get an error.
I have installed Net::Twitter, File::HomeDir and Config::Tiny using
cpanm Net::Twitter
etc.
(Note: no sudo) I get the following error when I run my script from my local crontab:-
Can't locate Net/Twitter.pm in #INC (you may need to install the
Net::Twitter module) (#INC contains: /etc/perl /usr/local/lib/arm-linux-
gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-
gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf
/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at /home/pi
/speedtest.pl line 99.
BEGIN failed--compilation aborted at /home/pi/speedtest.pl line 99.
Can someone please point me in the right direction? I suspect it has something to do with where Net::Twitter etc ended up but I've no idea how to fix it so that crontab knows where to find it.
speedtest.pl is here
The Perl installation that you run from the command line is different from the one run by the system when a crontab job executes
Try which perl, and then look at the output of the same command run under cron
There are a few ways to fix this, depending on the configuration of your system. The most obvious is to use the full path to your own copy of perl, but while that will probably get things going it is probably a bad idea
I think you may have installed Net::Twitter using your local account.
Logging into root & installing the module should fix this problem.
I have installed ActivePerl 5.14.2 on a Windows 32 bit machine running XP. My problem is that I'm trying to install a few modules with PPM and it's not working out.
According to ActiveState's website, all you need to do to install a module from their repository is "ppm install module name" , example: http://code.activestate.com/ppm/Template-Toolkit/
Every time I try this or any other module I get: "No Perl script found in input"
Even when I do just "ppm" I get the same message, even though the GUI should run.
When I run PPM with a GUI from the start menu I get this error: "Failed 500 Can't connect to ppm4.activestate.com:8080 (connect: timeout)”
I though that it might be my connection, so using cmd.exe I used the set HTTP_PROXY command and then tried ppm install, but still no luck. So is there any way I can get these modules installed?
Any advice is appreciated !!
Invoke the cpan prompt from your command prompt. Go to cmd and simply type cpan. If you successfully enter cpan prompt them there is probably no issues with your Perl installation. To install a module from cpan prompt just use
cpan>install Module::Name
Screenshot below shows command to install module Net::Stomp
If the above does not work, check if your FTP data and connection ports needs to be added to the Windows firewall exceptions (Ports 20 (FTP Command port) and 21 (FTP Data port)).
Alternatively (if you don't want to add port 20 21 to exception), you can go to the cpan prompt and use an ftp_proxy by
cpan> o conf ftp_proxy http://your.ftpproxy.com
and then issue install command. Or you can update your ../CPAN/config.pm file to make permanent changes to the ftp_proxy parameter.
The next step would be to try set the FTP_PASSIVE mode to 1. By default the libnetcfg configuration for this is set to 0. To change this find libnetcfg.bat file (should be somewhere C:\Perl\bin), open the file in an editor and replace
ftp_int_passive 0
to
ftp_int_passive 1
Again, looking at you r timeout error it seems that your network is blocking you from accessing the CPAN ftp mirrors, this would happen mostly if you are inside a corporate VPN. The solution to this can only be proxy servers.
I sometimes get this error when compiling a program:
make[1]: /usr/bin/perl: Command not found
make[1]: *** [links] Error 127
This happens with any program that requires perl to compile, such as openssl and automake. However:
sh-2.05b# perl -v
This is perl, v5.10.0 DEVEL34342 built for arm-linux-thread-multi
(with 1 registered patch, see perl -V for more detail)
sh-2.05b# /usr/bin/perl -v
This is perl, v5.10.0 DEVEL34342 built for arm-linux-thread-multi
(with 1 registered patch, see perl -V for more detail)
I definitely have perl installed. What's going on?
If this is reproducible, run the make command with strace -f, to see unambiguously which command is attempting (and failing) to exec.
I can recall from my own experience the following two situations in which an exec-family might fail on Linux with ENOENT despite that the command is actually there:
The .interp referred to by the binary isn't present (example: the LSB-compatible binary refers to /lib/ld-lsb.so.3 instead of the usual /lib/ld-linux.so.2, and LSB compatibility packages haven't been installed on the Linux machine). Seems unlikely in your scenario :)
Some kernel-level non-standard security mechanism is in place which is blocking execution of the binary - especially on locked-down embedded devices. One would think EACCES would be the more logical errno in this case, but maybe ENOENT is used to prevent leaking information about the existence of binaries to unprivileged processes.
Attempting to install the Perl module DBD::mysql on Windows 7
From the Windows command line I executed
perl -MCPAN -e 'install DBD::mysql'
Which downloaded and uncompressed the file -- then gave me this ERROR:
CPAN.pm: Going to build C/CA/CAPTTOFU/DBD-mysql-4.018.tar.gz
Set up gcc environment - 3.4.5 (mingw-vista special r3)
C:\PROGRA~1\MySQL\MYSQLS~1.1\bin\MYSQLA~1.EXE: connect to server at 'localhost'
failed
error: 'Access denied for user 'ODBC'#'localhost' (using password: NO)'
Problem running C:\PROGRA~1\MySQL\MYSQLS~1.1\bin\MYSQLA~1.EXE - aborting ...
Warning: No success on command[C:\Perl\bin\perl.exe Makefile.PL INSTALLDIRS=site
]
Guessing the issue is that MySQL's root user has a password, but what's not clear is how I resolve the issue.
Questions, feedback, requests -- just comment, thanks!!
----------
UPDATE (1): RE: force install DBD::mysql
cpan> force install DBD::mysql
Running install for module 'DBD::mysql'
Running make for C/CA/CAPTTOFU/DBD-mysql-4.018.tar.gz
Has already been unwrapped into directory C:\Perl\cpan\build\DBD-mysql-4.018-A
1T8Uh
'C:\Perl\bin\perl.exe Makefile.PL INSTALLDIRS=site' returned status 256, won't
make
Running make test
Make had some problems, won't test
Running make install
Make had some problems, won't install
On other platforms, the build process runs the mysql_config command to get necessary information about the mysql installation without need of a user and password; on win32, if you have a mysql_config command, you have to explicitly tell Makefile.PL about it with a --mysql_config yourpathname parameter. If you don't, it looks for the mysqladmin program and uses its location to determine as much as it can but runs mysqladmin version to get the mysql version. You can provide a user/password for it to be able to do this using --testuser and --testpassword parameters to Makefile.PL.
Following up on "Robert P" comment, I checked the install guide for installing DBD::MySQL in ActivePerl on Win32; on 64, but doesn't appear to have mattered.
Command that did the job was:
ppm install DBD::mysql
The only way I've got round this in the past is a forced install. It always feels like a bodge but I haven't been able to find a better way.
Open up a CPAN shell:
perl -MCPAN -e 'shell'
Then do a force install
force install DBD::mysql
quit gets you back out of the shell.
as ysth said , maybe try this :
cd C:\Perl\cpan\build\DBD-mysql-4.018-A
and run
perl Makefile.PL --testuser validuser --testpassword validpassword
and then try to make - make test - make install,
or its equivalents on windows
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.)