i am trying to use pp utility from PAR package to create an exe file of my Perl program on windows
eg
pp -o script.exe script.pl
The command runs ok, but when i try to run the exe, it gives me
The locale codeset (cp1252) isn't one that perl can decode, stopped at Encode/Locale.pm line 94. Compilation failed in require at LWP/UserAgent.pm line 1000.
What could be the problem? I have a list of modules being used in the script, these include, Cwd, LWP::Simple, LWP::Useragent , Win32::OLE.
enviroment:
1) windows vista
2) Activestate Perl 5.16
3) did not manage to install PAR::Packager successfully, unless i use "force" install, which manage to install.
thanks
Encode::Locale finds the modules it needs to decode various encodings in a way that pp can't discover automatically. You'll need to tell pp which additional modules are required.
This should do the trick:
pp -m Encode::Byte -o script.exe script.pl
Related
I'm packaging clusterssh to openSUSE and need to change default shebang from #!/usr/bin/env perl to #!/usr/bin/perl. clusterssh uses Module::Build.
I'll probably use the patch (as Debian package do), but I wonder easy usage for fix_shebang_line(#files) in RPM packaging.
It's already called during the building process.
Basically, uninstalled scripts should use #!/usr/bin/perl or #!perl, and the installation process should rewrite that to the point to the perl used to run the installer. That way, a script installed by /usr/bin/perl will use /usr/bin/perl, and a script installed using /home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl will use /home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl.
(This applies to both the Module::Build installer and the ExtUtils::MakeMaker installer.)
Note that the documentation for fix_shebang_line says it doesn't touch a shebang line of #!/usr/bin/env perl (because it's not recognized as invocation of perl), so simply patching the scripts to use #!/usr/bin/perl instead of #!/usr/bin/env perl does the trick.
With that change, the install-ready staging directory (blib) produced by ./Build will contain the edited files.
$ perl -e'CORE::say $^X'
/home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl
$ for fn in ccon crsh csftp cssh ctel; do printf '%-6s ' "$fn:"; head -n 1 "bin_PL/$fn"; done
ccon: #!/usr/bin/perl
crsh: #!/usr/bin/perl
csftp: #!/usr/bin/perl
cssh: #!/usr/bin/perl
ctel: #!/usr/bin/perl
$ perl Build.PL
Could not get valid metadata. Error is: ERROR: Missing required field 'dist_abstract' for metafile
Could not create MYMETA files
Creating new 'Build' script for 'App-ClusterSSH' version 'v4.13.203'
$ ./Build
Building App-ClusterSSH
Using perl binary: /home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl
Using perl version v5.26.2
Generating: /home/ikegami/tmp/clusterssh/bin_PL/cssh
Generating: /home/ikegami/tmp/clusterssh/bin_PL/csftp
Generating: /home/ikegami/tmp/clusterssh/bin_PL/ccon
Generating: /home/ikegami/tmp/clusterssh/bin_PL/crsh
Generating: /home/ikegami/tmp/clusterssh/bin_PL/ctel
Generating: /home/ikegami/tmp/clusterssh/bin_PL/clusterssh_bash_completion.dist
$ for fn in ccon crsh csftp cssh ctel; do printf '%-6s ' "$fn:"; head -n 1 "blib/script/$fn"; done
ccon: #!/home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl
crsh: #!/home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl
csftp: #!/home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl
cssh: #!/home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl
ctel: #!/home/ikegami/usr/perlbrew/perls/5.26.2t/bin/perl
I didn't bother running ./Build install, whose main task is to copy the files from the staging directory into their final locations. Besides, that part will need to be replaced by your package manager anyway (assuming you're simply placing the contents of the blib directory into your package).
If you somehow need to do it yourself, you could use the following:
find bin -type f \
-exec perl -i -pe'
s/^#!\S*perl\S*/#!$^X/ if $. == 1;
close ARGV if eof;
' {} +
Notes:
Use the perl you wish the scripts to use.
GNU tools assumed; adjust as necessary.
close ARGV if eof; resets the line number ($.) for each file.
eof is different than eof(), and only the former will work here.
The line breaks are optional and may be removed.
I am trying to build LDV project by following this instructions, and i know nothing about perl.
i am getting the following error while running the test
ldv-task: NORMAL: Calling LDV-core.
Can't locate SOAP/Lite.pm in #INC (#INC contains: /home/acsia/perl5/perlbrew/perls/perl-5.10.0/lib/5.10.0/x86_64-linux /home/acsia/perl5/perlbrew/perls/perl-5.10.0/lib/5.10.0 /home/acsia/perl5/perlbrew/perls/perl-5.10.0/lib/site_perl/5.10.0/x86_64-linux /home/acsia/perl5/perlbrew/perls/perl-5.10.0/lib/site_perl/5.10.0 .) at /home/acsia/Desktop/LDV/consol-tools/ldv-core/ldv-core line 7.
BEGIN failed--compilation aborted at /home/acsia/Desktop/LDV/consol-tools/ldv-core/ldv-core line 7.
output of
perlbrew use
is :EDITED:
Currently using perl-5.22.0
output of
locate SOAP/Lite.pm
is
/usr/local/lib/perl5/site_perl/5.22.0/SOAP/Lite.pm
output of
which perl
is
/usr/local/bin/perl
and the LDV-core file is starting like this by default
#!/usr/bin/perl -w
#
my $instrumnet = 'ldv-core';
use FindBin;
# To prevent meaningless module warnings use this instead of use.
BEGIN { $SIG{'__WARN__'} = sub{}; require SOAP::Lite; SOAP::Lite->import(); $SIG{__WARN__}='DEFAULT'; }
use POSIX ":sys_wait_h";
use XML::Twig;
use IO::Socket::INET;
#use File::MimeInfo;
use File::Basename;
use Cwd qw(abs_path);
etc,... etc....
Thanks for your time...
If LDV-Core isn't yours, you should install SOAP::Lite using your system's package manager. If it's yours, read on.
perlbrew plays with your PATH so that executing perl will execute the desired perl.
But your script explicitly uses /usr/bin/perl, so which perl is currently selected using perlbrew switch or perlbrew use is irrelevant.
Stop overriding the default install location, and stop looking where you shouldn't.
unset PERL_MM_OPT
unset PERL_MB_OPT
unset PERL5LIB
unset PERLLIB
echo -ne 'o conf makepl_arg ""\no conf commit\n' | cpan
echo -ne 'o conf mbuildpl_arg ""\no conf commit\n' | cpan
The first four lines only have a temporary effect. You should stop setting those variables in your login script to make the change permanent.
Install SOAP::Lite in the desired Perl.
perlbrew use perl-5.22.0 # Or perl-5.10.0 or whatever
cpan SOAP::Lite
Fix your script's shebang.
perl -i~ -pe'
next if $. != 1;
s/^#!.*//s;
$_ = "#!$^X\n$_";
' LDV-core
PS — You don't need use FindBin;.
perlbrew perl is a way to install many perl versions in same machine. It is like virtenv in python. Perlbrew allow you to switch between various versions of perl and run perl programs against those versions.
system perl means the default version of perl which mostly come with linux distros. perlbrew changes that version against which program needs to run and your program will start running against different version.
If you are making something which does not require a lot of perl versions it is always better to use one version of perl and run programs against them.
Also if you are using linux distros and do not want to get into cpan and how to install perl modules, best is to search for corresponding libraries against that module and install them. For example in your case i search this way
aptitude search soap | grep perl
This give me two libraries on my ubuntu machine of which one is against this module. Installing them is easy and you can focus on your work rather than on how to install cpan modules.
I used to delete my ActivePerl once, and all the installed modules were lost. So now I am very careful with this kind of issue. Due to some reason, I want to use Strawberry Perl now, while keeping ActiveState's ActivePerl in use.
Will this cause compatibility issues? Is it advisable?
This will not be a problem as both the Perl implementations will look at different directories for modules. That is, the #INC entries will be different.
I keep both ActivePerl and Strawberry Perl installed on my Windows 7 Pro instance. My PATH variable order decides my Perl preference. E.g, for using ActivePerl I set my PATH to something like this:
C:\Perl64\bin;C:\strawberry\perl\bin
You can always override this in your script using shebang:
#!C:\strawberry\perl\bin\perl
You could use two (many) different Perl versions at once.
Set your PATH variable to include your primary Perl path (path to perl.exe) to be sure that you are running the correct Perl when you start a program with perl script.pl.
You could use Perlbrew (or other modules) to help keeping multiple Perl installations on your computer.
It is available on Windows: http://code.activestate.com/ppm/App-perlbrew/
I found another solution for this. You could embed your Perl code into a Windows batch file. This way you could set environment variables before executing your Perl script or include your module path.
#echo off
cd %TEMP%
set perl_bindir=C:\strawberry\perl\bin
set module_dir=C:\my_perl_modules
set path=%perl_bindir%;%path%
echo Launching %0 perl script
%perl_bindir%\perl.exe -I %module_dir% -x -S %0 %*
goto endofperl
#!perl -w
use strict;
print "Hello World\n";
__END__
:endofperl
How do get the path of a installed Perl module by name,
e.g. Time::HiRes?
I want this just because I have to run my perl script on different nodes of a SGE Grid Engine system. Sometimes, even run as other username.
I can use CPAN.pm to install packages for myself, but it is not so easy to install for other users without chmod 666 on folders.
perl -MTime::HiRes -e 'print $INC{"Time/HiRes.pm"}' or perldoc -l Time::HiRes
Mostly I use perldoc to get a location:
$ perldoc -l Module
You can also get module details with the cpan tool that comes with Perl:
$ cpan -D Time::HiRes
Time::HiRes
-------------------------------------------------------------------------
High resolution time, sleep, and alarm
J/JH/JHI/Time-HiRes-1.9719.tar.gz
/usr/local/perls/perl-5.10.0/lib/5.10.0/darwin-2level/Time/HiRes.pm
Installed: 1.9711
CPAN: 1.9719 Not up to date
Andrew Main (Zefram) (ZEFRAM)
zefram#fysh.org
It even works on modules that you haven't installed:
$ cpan -D Win32::Process
Win32::Process
-------------------------------------------------------------------------
Interface to Win32 Process functions
J/JD/JDB/Win32-Process-0.14.tar.gz
Installed:
CPAN: 0.14 Not up to date
Jan Dubois (JDB)
jand#activestate.com
I think maybe I need an XML option like svn.
Note: This solution proposes use of a (self-authored) utility that you must download. While it offers what I believe to be helpful features, installing a third-party solution first is not an option for everyone.
I've created whichpm, a cross-platform CLI (Linux, macOS, Window) that locates installed Perl modules by module (package) name, and optionally reports information about them, including detection of accidental duplicates.
Examples
# Locate the Data::Dumper module.
$ whichpm Data::Dumper
/usr/lib/perl/5.18/Data/Dumper.pm
# Locate the Data::Dumper module, and also print
# version information and core-module status.
$ whichpm -v Data::Dumper
Data::Dumper 2.145 core>=5.005 /usr/lib/perl/5.18/Data/Dumper.pm
# Locate the Data::Dumper module and open it in your system's default text
# editor.
$ whichpm -e Data::Dumper
# Look for accidental duplicates of the Foo::Bar module.
# Normally, only 1 path should be returned.
$ whichpm -a Foo::Bar
/usr/lib/perl/5.18/Foo/Bar.pm
./Foo/Bar.pm
# Print the paths of all installed modules.
$ whichpm -a
Installation
Prerequisites: Linux, macOS, or Windows, with Perl v5.4.50 or higher installed.
Installation from the npm registry
With Node.js or io.js installed, install the package as follows:
[sudo] npm install whichpm -g
Manual installation (macOS and Linux)
Download the CLI as whichpm.
Make it executable with chmod +x whichpm.
Move it or symlink it to a folder in your $PATH, such as /usr/local/bin (OSX) or /usr/bin (Linux).
If need to find which modules are actually used by your script you can use perl debuggers M command:
[ivan#server ~]$ perl -d your_script.pl
...
Debugged program terminated. Use q to quit or R to restart,
use o inhibit_exit to avoid stopping after program termination,
h q, h R or h o to get additional info.
DB M
'AutoLoader.pm' => '5.60 from /usr/lib/perl5/5.8.8/AutoLoader.pm'
'Carp.pm' => '1.04 from /usr/lib/perl5/5.8.8/Carp.pm'
...
This will help in case when you have modules with same names but in different folder.
I just find another one:
http://www.perlmonks.org/?node_id=568730
#!/bin/sh
echo 'print map { sprintf( "%20s : %s\n", $_, $INC{$_} ) } sort keys %INC; print "\n'$1' version : $'$1'::VERSION\n\n"' | perl "-M$1"
the script just print out everything in %INC when you run perl -MSTH::STH
eg:
$ whichpm CGI
CGI.pm : /System/Library/Perl/5.8.6/CGI.pm
CGI/Util.pm : /System/Library/Perl/5.8.6/CGI/Util.pm
Carp.pm : /System/Library/Perl/5.8.6/Carp.pm
Exporter.pm : /System/Library/Perl/5.8.6/Exporter.pm
constant.pm : /System/Library/Perl/5.8.6/constant.pm
overload.pm : /System/Library/Perl/5.8.6/overload.pm
strict.pm : /System/Library/Perl/5.8.6/strict.pm
vars.pm : /System/Library/Perl/5.8.6/vars.pm
warnings.pm : /System/Library/Perl/5.8.6/warnings.pm warnings/register.pm : /System/Library/Perl/5.8.6/warnings/register.pm
CGI version : 3.05
I like to use the V module.
Just install it from CPAN or by installing the package libv-perl on Debian or Ubuntu.
Then use it like this:
$ perl -MV=DBI
DBI
/Users/michiel/.plenv/versions/5.24.0/lib/perl5/site_perl/5.24.0/darwin-2level/DBI.pm: 1.636
Other output example:
$ perl -MV=Time::HiRes
Time::HiRes
/usr/lib/perl/5.18/Time/HiRes.pm: 1.9725
It seems like the simplest way is perldoc -l Time::HiRes.
If that isn't available for some reason, here's a pragmatic solution:
Step 1: Instantiate the module in your script...
#! /usr/bin/perl -w
use Time::HiRes();
new Time::HiRes();
Step 2: Execute the script with the Perl graphical debugger...
export PERL5LIB=$PERL5LIB:~/perl ## tell perl where to look for "Devel"/"ptkdb.pm"
perl -d:ptkdb (yourscript.pl)
Step 3: Step in to the new call.
The full pathname of the module will be displayed on the title-bar of the debugger window.
Another approach that might be useful would be to search all of the folders in $PERL5LIB.
Perldoc -l works for me
perldoc -l "File::Find"
/opt/perl_32/lib/5.8.8/File/Find.pm
To expand on #Ivan's answer that allows this to be run without installing additional software the following will use Perl's debugger to find a specific module (or modules):
perl -de 'use <Module Name>;'
For Example:
perl -de 'use DBD::Oracle;'
Output:
Loading DB routines from perl5db.pl version 1.37
Editor support available.
Enter h or 'h h' for help, or 'man perldebug' for more help.
DBD::Oracle::CODE(0x27f81d8)(/usr/local/lib64/perl5/DBD/Oracle.pm:113):
113: $ENV{PERL_BADFREE} = 0;
DB<1> q
In OSX you can use:
perl -e 'print join("\n",#INC)'
The result should be the location of your lib.
Then add this code in your Perl code:
use lib '/your/folder/location/to/lib';
I'd like to have all the installed CPAN modules updated automatically every night, so I've placed the following command in the crontab:
#daily cpan -i $(cpanp -o | perl -lane 'print $F[3]')
However, whenever this is run I get the following error message:
Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS and
LINES environment variables didn't work. The resize program didn't work. at
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/Term/ReadKey.pm
line 362.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Term/ReadLine
/Perl.pm line 63.
What can I do to get this working?
Come back on Monday. I'll add a -u command to cpan to do that if you promise to test it for me. You'll have to get the latest cpan from App::Cpan.
Okay, don't wait until Monday. I've pushed the change to the cpan-script Github repo, and App-Cpan 1.56_15 is on its way to CPAN.
Let me know if you have any problems or the new feature doesn't do what you want.
Please use brian d foy's answer as he added a cpan option to do this
Are you trying to update the list of modules with CPAN or actually update any out of date modules (d/l, compile, install)? This could be dangerous as modules could change interface and existing scripts would fail. This error is due to CPAN trying to use Term::ReadLine and Term::ReadKey to interrogate the terminal.
If you really want to upgrade all your modules, you can use this command:
perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)'
This is a small change from the command given in the documentation to interrogate CPAN for all outdated modules:
https://metacpan.org/pod/CPAN#PROGRAMMERS-INTERFACE
The COLUMNS and LINES environment variables didn't work.
Try setting the COLUMNS and LINES environment variables.
COLUMNS=80
LINES=24
#daily cpan -i $(cpanp -o | perl -lane 'print $F[3]')