I have been using telnet to issue test commands to my Jabberd2 server. It is a clunky method, so I downloaded the sendxmpp package included with my build of Cygwin. When I issue the command sendxmpp -h I get the following error(minus the #INC path dump): can't locate Authen/SASL.pm in #INC BEGIN failed--compilation aborted at /usr/bin/sendxmpp line 21.
I think the problem is ldap related, however I have installed all of the perl and ldap modules available.
Does anyone know how to fix this error?
Are there additional configuration steps needed to get ldap working
with perl in the Cygwin environment?
Is there a better way to issue xmpp commands to Jabberd from the
command line?
Looks like you're missing the Authen::SASL module. If it's not part of the sendxmpp package, try installing it with cpan -i Authen::SASL. If it IS available, make sure sendxmpp (which may very well be a perl script) finds it, by modifying the inc/lib directory. If Authen::SASL is supposed to be installed and available systemwide, try executing perl -MAuthen::SASL. If that triggers an error, perl can't find it. If it just "hangs" there (waiting for input), perl did find the module, and sendxmpp should work.
Related
hi am trying to install perl module from cpan in my windows machine am getting below error after hitting two times yes .
Checking if your kit is complete...
Warning: the following files are missing in your kit:
README
Please inform the author.
Writing Makefile for Digest::Perl::MD5
'nmake' is not recognized as an internal or external command,
operable program or batch file.
nmake -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
Running make for D/DO/DOUGW/Spreadsheet-ParseExcel-0.65.tar.gz
Is already unwrapped into directory C:\Perl\cpan\build\Spreadsheet-ParseExcel
0.65
CPAN.pm: Going to build D/DO/DOUGW/Spreadsheet-ParseExcel-0.65.tar.gz
'nmake' is not recognized as an internal or external command,
operable program or batch file.
nmake -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
>perl exceltoxml.pl
Can't locate Spreadsheet/ParseExcel.pm in #INC (#INC contains: C:/Perl/site/lib
C:/Perl/lib .) at exceltoxml.pl line 4.
BEGIN failed--compilation aborted at exceltoxml.pl line 4.
I have tried 5 times.
nmake' is not recognized as an internal or external command
Sinan Ünür is right. The error message is that you don't have nmake installed. This means you are attempting to compile code (probably C code) and there's no C compiler or Make program.
A while ago, I would tell people that ActiveState doesn't fully support cpan because it can't compile code. ActiveState uses it's own pre-compiled packages available via the Perl Package Manager (PPM) which can be used from the command line or from a GUI interface. If a package isn't available via the PPM and it requires compilation, you were just out of luck. I would usually recommend Strawberry Perl instead of ActivePerl for this very reason. Strawberry Perl comes with the complete MinGW environment needed for those compilable CPAN modules.
However, about a half a dozen years ago, ActiveState put together an installable PPM package for the MinGW environment. Once this is installed, ActivePerl can use CPAN.
So you have two solutions:
Install this PPM package as Sinan Ünür mentioned in his answer. Then, try Spreadsheet::ParseExcel again.
Install Strawberry Perl instead of ActiveState's Perl. Strawberry Perl seems to be more compatible with the version of Perl found on Unix/Mac/Linux systems. Then try installing the Spreadsheet::ParseExcel package.
Okay, three solutions: Install Cygwin which will give you the complete Linux Environment on your Windows machine. It can take about two hours to install, but it comes with all of the GNU utilities you've known and love, most other Unix/Linux utilities, and the BASH shell.
It's what a lot of Linux/Unix homeboys use when they get sick of that ol' C:\> prompt. Cygwin comes with the latest version of Perl and works with every single CPAN package I've tried. There are a few minor issues (Like Termcaps) where things don't quite work the way they're suppose to, but I'm generally happy with it. It even comes with X11 and allows you to run XWindow apps, and even use XWindow apps across systems -- just like a REAL operating system does!
There maybe a few instances where CPAN modules may still have issues on Windows. One has to do with archiving and unarchiving modules and the missing libz library. However, installing this MinGW package (or using Strawberry Perl or Cygwin) will solve about 95% of the cpan installation issues.
I have tried 5 times.
Computers are deterministic things. That means, unless you change the conditions under which a program runs, it will always do the same thing (except, maybe, if there is a solar flare or an EMP).
So, there is no difference between issuing the same command once versus five times. If it failed the first time, ceteris paribus, it fill fail all five times.
That said, it looks like you installed ActiveState Perl, but did not install the MinGW package which provides the gcc & dmake based build tools.
So,
C:\>ppm install MinGW
and then try to install packages.
You also have the option of building your own perl using the Community Edition of Microsoft Visual Studio 2013 tools, or any other supported compiler.
I am trying to write perl program to make changes in Perforce.
When I run Perforce commands using P4 from the command line, those work fine but when I write "Use P4" in a perl program, it is not able to identify the P4 class.
Is there any configuration I might be missing?
P.S> -Since, it is working fine from a command line, I am assuming that my path is set correctly.
This is the error which I am getting:
Can't locate object method "new" via package "P4" (perhaps you forgot to load "P4"?) at perlP4.pl line 5.
This is my program:
use strict;
push ( #INC,"C:\Program Files\Perforce");
use lib "C:\Program Files\Perforce";
use P4; # a p4perl module
my $p4 = new P4;
Any help would be appreciated.
P4 module is stored in a file P4.pm. Try to find this module in your system to see it is installed or not.
If it is not installed, then please install it first.
http://www.perforce.com/perforce/doc.current/manuals/p4script/02_perl.html
I haven't used Perforce in a while, so I maybe out of date here:
The P4 module requires the Perforce C++ API library to be used, and there is quite a bit of compiled C programming with the P4 module. With Windows, much of this is already compiled (and I see you're using Windows).
Read the installation directions very carefully. Make sure you have the API libraries installed as well as the P4 module (and all of its sub-modules) installed. Since use P4; itself doesn't throw an error, I am assuming that the Perl portion of the P4 module is installed. The problem is communicating with the P4 C++ API.
The sub new subroutine isn't in the P4.pm module, but is part of the P4.xs XS package. If you have P4.pm installed, but you don't have the API setup correctly, you will get the error you're getting.
On your command prompt run the following:
perl -MP4 -e "print P4::Identify()"
If you have not installed the p4perl module you will see:
Can't locate P4.pm in #INC (#INC contains: /etc/perl /usr/local/lib/perl/....
.... (snip) ....
BEGIN failed--compilation aborted.
I have simple perl script and I want to make install script which install dependencies (perl modules) and copy my file.perl to /usr/share/path asking about password if necessary. I found that there are some solutions for installing perl modules (Makefile.PL, Build.PL etc.). But my script isn't module. How should I attempt it?
Makefile.PL/ExtUtils::MakeMaker support a EXE_FILES parm for perl script, you can see how App::Ack do this or check this tutorial. Just set the prefix to your directory and it should do the work for you.
I'm running into an unexpected amount of difficulty trying to use ses-verify-email-address. I am using Ubuntu Hardy on AWS with Perl 5.8.8.
After copying the Perl scripts and creating a key file, I got a "command not found" error. Then I installed the files mentioned in the SES README - Digest::SHA, URI::Escape, Bundle::LWP, MIME::Base64, Crypt::SSLeay and XML::LibXML. It's not obvious that these installed correctly and now when I run ses-verify-email-address.pl, I get the message "LWP will support https URLs if the LWP::Protocol::https module is installed."
I've been using Python and know nothing about Perl.
Install LWP::Protocol::https.
See What's the easiest way to install a missing Perl module? from the SO Perl FAQ, How to install CPAN modules on CPAN, and perlmodinstall in the Perl documentation.
I was getting the same error. It turned out not to be LWP::Protocol::https, but one of its dependencies. Try running perl -MLWP::Protocol::https -e 1 (source) to see if you get any error messages. That just tells perl to include that module and then return the value 1, so there's no harm in running the command. If you get nothing in return that means the module is installed correctly. I suspect you'll get an error message. In my case I was missing Net::SSL, so running perl -MNet::SSL -e 1 also gave an error message.
I'm new to Perl. I get the following error when I run a script:
Can't locate URI.pm in #INC (#INC contains: /usr/local/packages/perl_remote/5.6.1/lib/5.6.1/i86pc-solaris /usr/local/packages/perl_remote/5.6.1/lib/5.6.1 /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/i86pc-solaris /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1 /usr/local/packages/perl_remote/5.6.1/lib/site_perl .) at (eval 2) line 3.
Compilation failed in require at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/HTTP/Request.pm line 3.
Compilation failed in require at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/LWP/UserAgent.pm line 10.
BEGIN failed--compilation aborted at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/LWP/UserAgent.pm line 10.
Compilation failed in require at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/LWP/Simple.pm line 26.
BEGIN failed--compilation aborted at /usr/local/packages/perl_remote/5.6.1/lib/site_perl/5.6.1/LWP/Simple.pm line 26.
Compilation failed in require at txotf_0_install.pl line 35.
BEGIN failed--compilation aborted at txotf_0_install.pl line 35.
What could be the possible reasons of this and how do I get the script to work. Any help will be appreciated.
Possibly you do not have URI installed. It might not be saved anywhere on your machine, or it might be "installed" in a location.
If it's just not installed, then you need to install it from CPAN.
If you have it saved to your machine, you just need to let the system know where to get it.
If you have to install it from CPAN, you likely need administrator privileges to put it in the listed directories. But CPAN will allow you to install it to a user directory, so you can still install it.
So if you can't install the module in the directories listed in #INC, then there are the various ways.
Perl 5 reads a environment variable called PERL5LIB. Any directory in that "array" will be prepended to #INC. So anything in the directory structure of $ENV{PERL5LIB} will be preferred to any system directory. (see here)
Another way you can do this is per script. The use lib pragma also inserts specified directories into #INC. (see lib)
use lib '/path/to/URI/module';
use URI;
The final way, you can do it per run. You can run perl with the -I switch on the command line perl -I/path/to/URI/module -e 1 (see perlrun)
The nonstandard paths in #INC (e.g. /usr/local/packages, perl_remote etc) indicate to me that this is a custom perl installed for a specific purpose probably with reduced functionality to prevent mischief.
Ask the sysadmin.
The array #INC contains the list of places to look for Perl scripts to be evaluated. Your script will not run because it is not in the #INC list. Either:
Put the script in one of the #INC locations; or
Add the location of the file to the $PATH environmental variable; or
Specify the full path of the script when you are calling it.
This is not to say that any of the other answers aren't all good advice (they very likely address your issue), but I ran into a similar issue which had me puzzled for a couple hours. While I'm not sure this addresses the OP's problem, perhaps someone stumbling across this in the future will save themselves some time troubleshooting...
I found on a new CentOS server that despite #INC reporting the path to my custom libraries included and despite all file and directory permissions being set correctly mod_perl was still bailing out with a message that it "Can't locate" the modules in question. This was doubly puzzling because similar scripts with the same "use lib" statement that Apache's PerlRequire was using were able to run without issue.
The culprit turned out to be SELinux, and disabling it took care of this immediately. More details on the /var/log/messages info that led me to this as well as other general gripes can be found here.
In my case I just copied the perl folder to another machine and added path to bin folder to PATH environment variable. In order to fix the issue, I had to run the proper installation of ActivePerl which at the end setup all the environment properly for perl.