Does that mean have another perl folder containing complete perl
installation? If that's true, not sure if I can just download Perl 5.8...
Essentially, yes, the complete Perl installation (binary, modules,
etc.) can be put under a specific directory (plus subdirectories, of course).
Note however, that if you download a prebuilt Perl distribution,
there will be some installation path hardcoded in the binary, which
means you can't arbitrarily move around the installation — for
example, if the original hardcoded path is /opt/perl, you can't
simply put it into /usr/local/perl/5.8.8 or similar. The
reason for this is that perl needs to find its associated Config.pm,
which then contains all the other settings, like where to look for the
modules that belong to that version, etc. (This applies to
unix-ish systems only, on Windows this is a non-issue.)
For this reason, you might want to build your own perl from source,
so that you can specify the installation path yourself at build time...
That said, there is a new feature
"relocatable @INC"
(i.e. Configure option -Duserelocatableinc, introduced with
5.10), which effectively allows modules to be found relative to
where the perl binary is installed — IOW, the installation can
now be moved around freely. If you're lucky, you might find a prebuilt
perl v5.10 that's been configured with this option.
| [reply]
[d/l]
[select] |
If I end up installing separate Perl, how can I run the code under this version in stead of stock perl? Thanks!
| [reply] |
Just call the respective perl binary — either directly via its absolute path (typically in the shebang line of your script), or adjust your executable search path (PATH env var) such that the correct perl instance is found first (for when you type "perl somescript.pl" on the command line).
If things are configured correctly (which is essentially what I was talking about in the last post), the perl binary should find the modules that belong to it — and preferably only those... which is why it's usually not a good idea to globally set the environment variable PERL5LIB, if you have multiple perls installed (paths in PERL5LIB are being prepended to the configured/hardcoded module search paths in the binary and Config.pm, which could lead to modules being mixed up across different Perl installations).
An easy way to check if things do work as desired is to simply invoke "perl -V" (capital V), or "/usr/local/perl/5.10/bin/perl -V" (or whatever you have installed) — which prints the perl version and all search paths being used (the latter near the end of the output).
| [reply]
[d/l]
[select] |
I would imagine that the approach to using the stock Perl or not should be cleared with your customer, because in the end, you have to ship your program to their machine.
You can download Perl from CPAN or http://perl.org.
If you are not familiar with sysadmin stuff, you will either have to become familiar with it yourself, or get a sysadmin to consult with.
| [reply] |