To set the environment prior to the execution of perl, invoke:
eval `perlenv`
This command is *only* to be used to prepare the environment to execute Perl scripts in "Recovery Script" trees. See perl_modules(3) for information regarding this usage.
When writing Perl scripts for WA2L/edrc, do *not* use perlenv, start the script thru the .perl_wrapper. See perl_wrapper(1) for information about integrating a Perl script into WA2L/edrc.
The directory structure in edrc/lib/perl/pm/ is:
Legacy Structure:
perl<rel>/<vers>/
perl<rel>/site_perl/<vers>/
perl<rel>/vendor_perl/<vers>/
perl<rel>/edrc_perl/
perl<rel>/share/<vers>/bin/
perl<rel>/share/<vers>/man/
perl<rel>/share/site_perl/<vers>/bin/
perl<rel>/share/site_perl/<vers>/man/
perl<rel>/share/vendor_perl/<vers>/bin/
perl<rel>/share/vendor_perl/<vers>/man/
New Structure:
perl<rel>/<vers>/root/
perl<rel>/edrc_perl/
Where <rel> is the major version number (e.g. 5) and <vers> is the whole perl version (e.g. 5.14.3).
The "Legacy Structure" and the "New Structure" can be and is mixed. However, the "Legacy Structure" will not disappear and all files will remain as they are; new modules will be installed into the more simple "New Structure". When using the .perl_wrapper to start a perl script and the perlenv commands to initialize the perl environment, scripts need no change.
See also: perl_modules(3), pmdesc(1).
To start a Perl script that uses a bundled Perl module from a recovery script, set the Perl library path (@INC) using the 'eval `perlenv`' command in the recovery script and then call the perl interpreter.
Recovery script:
#!/bin/ksh # # 1:ascript - A Recovery Script # # [00] 08.02.2009 CWa Initial Version # # test "$DEBUG" = True && set -x : : eval `perlenv` perl ./perlscript :
Perl script:
# # perlscript - Perl script using bundled DBI module # # [00] 18.03.2009 CWa Initial Version # : : use DBI; :
Create an _env file (using the env edrc command) and start the Perl script from the recovery script.
_env file:
# # _env - Environment settings for commands in /apps/eg # # [00] 18.03.2009 CWa Initial Version # # test "$DEBUG" = True && set -x eval `perlenv` :
Recovery script:
#!/bin/ksh # # 1:ascript - A Recovery Script # # [00] 08.02.2009 CWa Initial Version # # test "$DEBUG" = True && set -x : : perl ./perlscript :
Perl script:
# # perlscript - Perl script using bundled DBI module # # [00] 18.03.2009 CWa Initial Version # : : use DBI; :
Create an _env file (using the env edrc command) and write the recovery script in Perl.
_env file:
# # _env - Environment settings for commands in /apps/eg # # [00] 18.03.2009 CWa Initial Version # # test "$DEBUG" = True && set -x eval `perlenv` :
Perl recovery script:
#!/usr/bin/env perl # # 1:ascript - A Recovery Script # # [00] 08.02.2009 CWa Initial Version # : : use DBI; :
Note the use of '#!/usr/bin/env perl' in the magic key to start the Perl script. This ensures that the perl interpreter is found on the system, even when it is not installed in the default location you will normally specify. The path to the perl interpreter is added to the $PATH using the perlenv command.
The startup method method (see also: https://perldoc.perl.org/perlrun) below allows to start the perl interpreter from wherever it is installed and also enables to use all perl modules bundled with WA2L/edrc using the perlenv command to dynamically initialize the environment.
This method is similar to the use of the .perl_wrapper, but the perl script can be placed somewhere of your liking outside of WA2L/edrc.
Set the permissions of the script to executable:
chmod +x perlscript
Perl script:
#!/bin/ksh
#
# perlscript - Perl script using bundled modules
#
# [00] 18.03.2009 CWa Initial Version
#
eval `~edrc/lib/perlenv`
#! -*- perl -*- -p
eval 'exec perl -x -SS $0 ${1+"$@"}'
if 0;
use strict;
use warnings;
use File::Basename;
use REST::Client;
use JSON;
use DBI;
use Data::Dumper;
use Getopt::Std;
use WA2L::Util;
:
:
Set the needed perl environment:
[ / ] [ root@acme007 ][*edrc*/bash]: eval `perlenv`
Try to access the perl module:
[ / ] [ root@acme007 ][*edrc*/bash]: perl -e "use REST::Client;"
If an error message like
Can't locate REST/Client.pm in @INC (you may need to install the REST::Client module) (@INC contains: /etc/perl ... /usr/lib/x86_64-linux-gnu/perl-base) at -e line 1. BEGIN failed--compilation aborted at -e line 1.
appears, the module cannot be found, if the module can be found there is no output.
Be aware, that the perlenv and .perl_wrapper commands are a bit less strict in the resolution of the directories listed in the $PERLLIB environment variable.
Perl 5.14 is not binary compatible with earlier versions of Perl. In other words, you will have to recompile your XS modules.
In general, you can usually safely upgrade from one version of Perl (e.g. 5.X.Y) to another similar minor version (e.g. 5.X.(Y+1))) without re-compiling all of your extensions. You can also safely leave the old version around in case the new version causes you problems for some reason.
Usually, most extensions will probably not need to be recompiled to be used with a newer version of Perl. Here is how it is supposed to work. (These examples assume you accept all the Configure defaults.)
Suppose you already have version 5.8.7 installed. The directories searched by 5.8.7 are typically like:
/usr/local/lib/perl5/5.8.7/$archname /usr/local/lib/perl5/5.8.7 /usr/local/lib/perl5/site_perl/5.8.7/$archname /usr/local/lib/perl5/site_perl/5.8.7
Now, suppose you install version 5.8.8. The directories searched by version 5.8.8 will be:
/usr/local/lib/perl5/5.8.8/$archname /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/$archname /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7/$archname /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/
Notice the last three entries -- Perl understands the default structure of the $sitelib directories and will look back in older, compatible directories. This way, modules installed under 5.8.7 will continue to be usable by 5.8.7 but will also accessible to 5.8.8. Further, suppose that you upgrade a module to one which requires features present only in 5.8.8. That new module will get installed into /usr/local/lib/perl5/site_perl/5.8.8 and will be available to 5.8.8, but will not interfere with the 5.8.7 version.
The last entry, /usr/local/lib/perl5/site_perl/, is there so that 5.6.0 and above will look for 5.004-era pure perl modules.
Lastly, suppose you now install 5.10.0, which is not binary compatible with 5.8.x. The directories searched by 5.10.0 (if you don't change the Configure defaults) will be:
/usr/local/lib/perl5/5.10.0/$archname /usr/local/lib/perl5/5.10.0 /usr/local/lib/perl5/site_perl/5.10.0/$archname /usr/local/lib/perl5/site_perl/5.10.0 /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/
Note that the earlier $archname entries are now gone, but pure perl modules from earlier versions will still be found.
This way, you can choose to share compatible extensions, but also upgrade to a newer version of an extension that may be incompatible with earlier versions, without breaking the earlier versions' installations.
This is free software; see edrc/doc/COPYING for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.