ActiveState Perl installs an IIS script mapping for the extension .plx. Is this actually used in real life or just something specific to ActiveState?
No, it's not just from ActiveState. O'Reilly's Learning Perl on Win32 systems recommends naming scripts with a .plx extension to disambiguate them from perl modules (with .pm) and non-executable perl libraries (.pl). Nowadays however I'd name anything that is going to be directly run as .pl.
This is a matter of personal preference. It is not something unique to ActiveState. PLX stands for Perl Executable Script which is perhaps a bit more defined then PL which stands for Perl Script (apparently originally Perl Library as another user wrote). However, on CPAN you see numerous places where PLX is used as extension so it is perhaps not so rare as it seems:
On CPAN acx.plx
kobesearch.cpan.org on SerialPort
tag.plx on CPAN
etc.
UPDATE: here's an earlier discussion of the same discussing whether *.pl or *.plx should be used. It also mentions that Prolog uses *.pl as well and playlist is yet another use.
Google shows some matches and there are quite a few of them on CPAN. In fact, originally, .pl stood for 'Perl library'.
Related
I copied a Perl module (DBD::Pg) from one system to another to run some quick checks on a Mojolicious project. On the new system, it all works fine when I run it under morbo (the Mojolicious test web daemon). But when I try to run the tests (via the Module::Build installer), I get the error:
Perl API version v5.16.0 of DBD::Pg does not match v5.20.0 at /usr/local/lib/perl/DynaLoader.pm line 216.
I researched why I am getting this, and read the explanation in the perldoc. But since the project runs under morbo, that seems to imply to me that the version mismatch may be trivial in this case. It looks like PerlXS does make some allowances for disabling VERSIONCHECK, but I don't see how that can be applied when running a Perl script.
You can't copy non-pure Perl modules from one system to the next (or into one group of perl lib directories into another perl's). Generally the code in those modules is compiled against the specific perl binary. That binary could have linked to different libraries, changed how it does things, used a different compiler, and many other things. It may not even work if the perl versions are the same.
Instead, install the DBD::Pg for each perl that needs to use it.
I am working on creating an agent in perl which does several actions. It uses several modules which are in .pm format and also few libraries. Now i want to convert it as one executable file so that i can install in n number of servers by copying that single file. Is it something i can achieve in perl? I am just a beginner in perl, perhaps my question might sound dumb but it will teach me something.
pp script provided with PAR::Packer is able to create single-file executables. An example from its page:
pp -o foo foo.pl bar.pl # Pack 'foo.pl' and 'bar.pl' into 'foo'
Some modules are included with Perl, so even though they're separate modules, they will work on other Perl installs without installing those modules. These include File::Copy, File::Find, Time::Piece.
You can see the listing of all standard modules on the Perldoc home page. Be sure to set the drop down version field (located on the left side) to the version that you're using. It goes all the way back to Perl 5.8.8 which is on Solaris.
It is entirely possible that the modules you need are already included in the standard Perl distribution, so there's no need to worry. Sometimes, you can substitute a non-standard module that's being used for one that's a standard module with little rewriting.
Some modules include compiled C code and can't be redistributed. They must be compiled on the machine they'r running on and installed. However, most modules are pure Perl modules, and can be redistributed with a program.
If a module isn't a standard module, and it's a pure Perl module, there are two ways it can be redistributed:
Perl has an #INC list that says what directories to search for when you search for modules. There's a Perl use lib pragma that allows you to add directories. You could include modules as sub directories for your program, and then zip up the entire structure. Users would unzip the entire directory tree which would include your program and the modules you need. By the way, the default #INC usually includes the current directory.
The other way is to append the modules to your program and then remove the use statement for that module (since it's now part of the file). This is a bit tricky, but it means a single program file.
Just remember that a module might require another module, so check thoroughly.
Another thing you can do is check for the module, and if it isn't there, download it via CPAN. Testing is easy:
BEGIN {
eval {
require My::Module; Module->import( LIST );
};
if ($#) {
die qq(Module doesn't exist);
}
}
Of course, doing a die is sort of silly because use would do that. However, it might be possible instead of dying to load the module via the CPAN module programmer's interface. I've never done that, and I don't know people who have. But, it is possible.
So, your best bet is to check to see if your program uses standard Perl modules, and if not, see if you can modify the program to use them. For example, if your program uses Archive::Zip, you might be able to modify it to use IO::Uncompress::Unzip and IO::Compress::Zip instead.
Otherwise, your choice is to try include those modules for installation (and watch for recursiveness and non-Pure Perl modules) or to try to detect that a module isn't installed, and programmatically install it.
The answer is a bit complicated.
The nature of Perl makes it practically impossible to compile a perl script in most use cases, so that a single executable could be distributed (with executable in the Windows sense). There are ways to do something similar, but sadly I don't know them.
But you can actually embed the Perl interpreter inside any C application, including the Perl source (your scripts + modules). When you statically link all C libraries, this should work as well. You can then use the Perl API to call your scripts.
If all of the servers you target are guaranteed to run the exact same OS, using the exact same libraries, and are preferably a *nix of some sort, it would be possible to pack all required files into an archive and write an install script. It is possible to write self-extracting shell scripts that contain the archive they are about to unpack. Same goes with perl, using the special __DATA__ command and the DATA filehandle:
#!/usr/bin/perl
print for <DATA>;
__DATA__
1
2
3
prints
1
2
3
Works great for piping data to tar as well.
You should include all dependent modules and all compiled libraries into the file and figure out a metadata system to install all files to the correct place.
As a general rule, software should rather be compiled on the target system itself, than just copying the binary files. It is too easy to overlook architecture differencies, configuration files or special registration entries hidden from view.
If you have to target different systems, it might be better to write a script that delegates the bulk of the installation to cpan or whatever perl package manager you prefer. This will be more flexible than hard-coding filepaths.
#!/bin/bash
cpan install Foo::Bar
cpan install Acme
cpan install ...
# etc.
I would stick with that.
The most elegant solution would be to create your own package or distribution like the ones you download from CPAN. As you would include a metadata file referencing all your dependencies, cpan would figure out everything by itself and do possibly neccessary compilation. I don't think this exactly is a beginners topic, but it would give you max flexibility and maintainability (easy upgrades!). This should make it fairly easy to include some installation tests.
This is just for starters, I am sure the internet or somebody else with more knowledge will elaborate.
I'm looking for a light and portable perl release and found this one, but it seems there is no activity since 2003, which could be ok for me but I want to know if there is known issues.
So, if you can provide me some feedbacks, you're wellcome :)
From my experience, the best way to make distributable Perl scripts for Windows systems is to use a packager like PAR::Packer or ActiveState's PerlApp.
Of course this only works if you don't need to do anything on the fly. But it works really well if you have a collection of scripts that you want to move around and use on many systems.
As a replacement for .bat files, as you indicate in your comments, I have found that I can install enough CPAN modules with Strawberry Perl to make more-or-less cross-platform Perl scripts.
See also Is there a portable Perl? which points to the portable version of Strawberry Perl
There is also a Portable Perl from PortableApps
NB: I have used neither one
I've written any number of perl modules in the past, and more than a few stand-alone perl programs, but I've never released a multi-file perl program into the wild before.
I have a perl program that is almost at the beta stage and is going to be released open source. It requires a number of data files, as well as some external perl modules -- some I've written myself, and some from CPAN -- that I'll have to bundle with it so as to ensure that someone can just download my program and install it without worrying about hunting for obscure modules.
So, it sounds to me like I need to write an installer to copy all the files to standard locations so that a user can easily install everything. The trouble is, I have no idea what the standard practice would be for this. I have found lots of tutorials on perl module standards, but none on perl program standards.
Does anyone have any pointers to standard paths, installation proceedures, etc, for perl programs? This is going to be complicated by the fact that the program is multi-platform. I've been testing it in Linux, but its designed to work equally well in Windows.
Take a look at PAR and PAR::Packer. You can bundle all of your requirements (even non-Perl requirements) into one file. With PAR::Packer, the user doesn't even need to have Perl installed for it to work.
You might also look at how the various App::* distributions are setup.
The standard installers for modules (ExtUtils::MakeMaker, Module::Build, Module::Install) also work the same way for scripts.
Using such a standard Perl tool will help you to:
distribute your application on the
CPAN (and you'll benefit from
automated tests on various platforms
by CPAN Testers), and so your app
will be installable (with all its dependencies) from the CPAN
shell
help packagers of Linux/BSD distributions to make packages for your product
PLDelphi is a Perl project hosted on CPAN. I am currently working on a Delphi application and I am investigating the possibility of adding Perl scripting support and read about PLDelphi.
Ideally, I'd like my application to not require Perl to be installed. PLDelphi claims to support this:
To use PLDelphi from your Delphi
application without need to install
Perl you will need this files in the
main diretory of your application:
PLDelphi.dll - The PLDelphi
library that loads the Perl
interpreter. PLDelphi.pm - Perl
side of PLDelphi. Perl56.dll -
The Perl library in case that you have
Perl built dynamic. PLDelphi_dll.pas -
PLDelphi classes and DLL wrapper.
lib/* - A Perl lib directory with basic .pm files (strict, warnings, etc...)
I am aware of RemObjects PascalScript and embedding Python in Delphi, but in this instance, I am interested primarily in Perl support.
Has anyone used PLDelphi with success? Or have you found other ways to execute Perl scripts from Delphi without the full Perl installation available locally?
EDIT:
To be more clear, I found 1 potential solution and that is using PLDelphi. However, I'd like to know if anyone has used it (last updated in 2004) before, and how well it worked.
I'm also interested in hearing about any other options for embedding a Perl interpreter with Delphi.
You could use Windows Script Host (which comes with VBScript and JScript by default) and install PerlScript from ActiveState.
Sadly PLDelphi isn't updated for XE3 or 64 bits there for won't work with Perl 5.16
I was really looking for a solution that didn't require installing anything on the client. It appears that PLDelphi is not working with ActivePerl 5.10...so I don't believe there is a ready solution to embedding Perl within a Delphi application.