I need to run 2 versions of perl on Windows 7.
The first one is bundled with VMware vCLI, it is Active State Perl 5.8.8.
The one I need for script dev is Stawberry 5.12.4 (something like that).
When I type perl -v It calls the AS perl which does not seem to support things like named captures and other things I took for granted in perl.
Both perls are installed I just don't know how to call Stawberry instead of AS perl.
Any idea?
Your specific problem can be addressed by editing the PATH environment variable, as noted by David Heffernan.
System control panel
> Advanced system settings
> Environment variables
> Path
> Edit...
More broadly, here's the general approach I am currently using to manage multiple versions of Perl, Python, etc. on Windows 7. I would appreciate tips for better ways to do this.
I create a Perl installation area like this:
C:\usr\perls\
5.10\
5.12\
etc.
current # Symbolic link.
In that same area I create a symbolic link (current) referring to the version I want as my default, and I make sure that all Perl references in my PATH environment variable use current rather than specific version numbers.
# Open cmd window as an administrator.
cd C:\usr\perls
mklink /D current 5.12
Under that approach, I can quickly modify my system's default Perl by changing one symbolic link rather than making multiple edits to PATH, which is a more tedious.
In addition, I add a directory to my PATH containing batch scripts to invoke specific Perls.
C:\usr\bin
perl5.10.bat
perl5.12.bat
etc.
Those scripts look like this example:
# C:\usr\perls\5.12\perl\bin\perl.exe %*
I'd do this by changing the PATH environment variable. Make it point to the 5.12 version and you may find that the VMware code continues working because it knows where to find it its Perl. If not, make a .bat file that sets PATH to refer to the 5.12 installation and use that to launch into a cmd window from which calls to perl invoke 5.12.
Related
I got a huge project written on Perl, which contains many of scripts which starts with typical #!/usr/bin/perl
For this project I need a custom-built Perl to be compiled from source.
I tried just to replace /usr/bin/perl with my compiled one but OS becomes broken (for ex. module version mismatch etc).
So is there any correct way to replace system perl with my own-built one or the easiest way would be to edit all tons of scripts and replace /usr/bin/perl with /usr/local/bin/perl or something like this?
Do not replace system perl (or system binaries in general). You can build it to another location (as you suggested, /usr/local for example) and call it manually.
My personal preference is to use plenv. There's a nice guide here to get you started.
If you admin the server and other users are logging in an using your scripts, you'll want to build plenv somewhere outside your home directory (eg. /opt/plenv) and ensure that all users $PATH is prepended with the bin path of your new perl. Without digressing too much, this can be done in /etc/profile or even better to declare you custom profile mods in a custom profile script (eg. /etc/profile.d/custom.sh).
I would also suggest using a more portable shebang such as #!/usr/bin/env perl which will use whichever perl is in a users $PATH first. The only exception to this is cron jobs, which I typically always hardcode full paths. (This is a personal preference based entirely how I admin my boxes and probably not a good idea to recommend unless you know the full repercussions. Administering a server is entirely subjective based on it's use-case, your use-case likely differs vastly from mine).
According to comments, there is no solution to replace system Perl without of destroying something but the're 3 solutions to solve the descibed problem. For all of them i need to modify all the scripts.
Using #!/usr/bin/env perl (need to be very careful and place custom perl bin path before all at $PATH of user which runs the script. The nice solution would be to set PATH exactly at crontab.
Using straight new perl path at shebang like as #!/usr/local/bin/perl5.26.1
Totally remove shebang from scripts and use plain calls at cron and manual runs - like as /usr/bin/perl script.pl. Or just use plain calls - shebang would be ignored.
Special thanks to #Joshua and #ikegami
My question is I have folder containing 3 scripts(perlx2 and shellx1) and an internal folder of data that I wish to use in the perl scripts.
The shell script calls the two perl scripts consecutively the first one creating a file and the second one performing an analysis of the data from the created file.
From reading I could use Active perl or something of the sort to package the Perls scripts to be executable for a basic windows user. However I think it would make more sense if I made a sort of Batch file that will run the whole set of programs.
Sorry about my lack of knowledge I would love some help with this.
Thanks!
Running perl scripts from a .bat in Windows
Installation & Configuration of perl
First, install perl (I prefer Strawberry Perl but ActivePerl will work too).
This should put perl in your path, to check open up a command line and type:
echo %PATH%
You should see C:\strawberry\perl\bin in there (perl is in that directory).
Adding perl to your path (skip if already present)
Navigate Start -> Settings -> Control Panel -> System -> Advanced -> Environment Variables. Choose Path and append the following to the variable:
;C:\strawberry\c\bin;C:\strawberry\perl\bin
Close your command shell and open a new one. Retry echo %PATH%.
Assuming perl is in your path now...
Make a file called perlscripts.bat and type the following:
perl c:\path\to\scripts\script1.pl
perl c:\path\to\scripts\script2.pl
Running this batch should run the scripts in order as desired.
The shell script calls the two perl scripts consecutively the first one creating a file and the second one performing an analysis of the data from the created file.
You can directly call those perl scripts from perl itself, it will work in both windows& linux, why shell/batch, why need bother every time for different OS.
like, <script to run>
I have downloaded strawberry PERL and writing one application with CGI Perl Apache on Winxp sp3).
One of the libraries (written by someone else) which I using uses XML::LibXML. When i load the page it gives Internal Server Error. From Apache error log i can see this error:
Can't load 'C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll' for module XML::LibXML: load_file:The specified module could not be found at C:/strawberry/perl/lib/DynaLoader.pm line 190.
C:/strawberry/perl/site/lib/auto/XML/LibXML/LibXML.dll exists with all permissions.
Also this library works properly on Linux. My application also works fine if I remove all code that needs LibXML.
Can anyone tell me when can be possible issue here.
If you peek into the source for DynaLoader you'll find
Many dynamic extension loading problems will appear to come from
this section of code: XYZ failed at line 123 of DynaLoader.pm.
Often these errors are actually occurring in the initialisation
C code of the extension XS file. Perl reports the error as being
in this perl code simply because this was the last perl code
it executed.
You should have also gotten (but may not have noticed) the following dialog, which provides a more accurate error message:
The problem isn't that perl can't find LibXML.dll; it's that LibXML.dll can't find the real libxml. (The former is just a wrapper that provides Perl bindings for the latter.) To fix that you need to ensure that Strawberry Perl's c\bin folder is in your PATH. In your case, that would be C:\strawberry\c\bin.
You might have to check the environment variable settings in the windows,
make sure that the installation path of the module is present in the PATH variable.
The reason it works in linux is that make files usually set the environment variables for you in linux in windows it may not have set properly.
For eg;
go to Control Panel\System and Security\System click change settings then advanced tab in user variable section see if there is a variable called perl5lib.
if not create an new perl5lib variable and add the path of your library ( usuall C:\Perl\site\lib but may be different in your case)
I had the same issue after installing Strawberry perl. It was working fine when I run the script from server, but not remotely from a automation tool. The issue was because of the Environment variables not updated when we run it remotely. So I did server reboot, which resolved the issue.
I encountered the same problem recently, in my case it was not related to PATH variable (it was already correct). The thing is I was executing my script from Git Bash console and as it turned out git-bash perl was being used instead of Strawberry (see git-bash perl should not be first in path). Switching to standard Windows CMD terminal helped.
Is possible to use different version of Perl without using the SET or manipulating the environment variable "PATH"
I need a mechanism that allows me to work with different version of Perl for different script without affecting the system configuration.
(e.g. I am using Perl ver 5.6.1 for some scripts and perl 5.8.8 for other Perl scripts)
It's an old trick I do when I have two different, but very incompatible versions of Perl I have to use: Use different suffixes:
For example, I have ClearQuest on my system and must use cqperl (which is ClearQuest's version of Perl) to execute scripts that manipulate the issues in ClearQuest. Yet, if I have to manipulate SQL data from our database, I have to use my ActivePerl because I can't add in the DBI module into cqperl.
What I did was associate the *.pl suffix with ActivePerl and the *.cqpl suffix with cqperl. Now, when I execute a script, and it ends in *.cqpl, it uses one version of Perl while a script that ends with *.pl is executed by another version of Perl.
To associate a suffix with a program, go into a Windows Explorer window and select Folder Options from the Tools menu. Then, click on the File Types tab. Click on the New button and create a new extention to associate with the file. Then, select it in the Registered File Types window, and click on the Advanced button on the bottom.
Create an Open action, and associate it with the full path name of the Perl you want to execute that suffix. Like this:
"C:\Perl\bin\perl.exe" "%1" %*
The %* is important, so you can pass other parameters to your program.
In your case, you could use *.pl for Perl 5.8.8 and *.pl6 for Perl 5.6.
You don't even need to put Perl's bin directory in your path. Just type the name of your script and that's it.
On Unix: use shebang line.
On Windows: when perl is installed, it usually created two executables: perl.exe and perl5.N.M.exe. For ex. in my Strawberry installation I have perl.exe and perl5.10.1.exe. So if both perls are in PATH, you can call them as perl5.6.1 and 5.8.8.
I.e "perl5.6.1 program.pl".
P.S. I'd suggest to upgrade whole environment to 5.12.2 - Perl has many new useful features.
you can always just run your scripts using the perl interpreter of your choice,
let's suppose you have 2 different perls installed in с:/perl_56 and c:/perl_58.
in CMD.exe you can try this:
c:/perl_56/bin/perl.exe path_to_your_script here
and
c:/perl_58/bin/perl.exe path_to_your_script here
to run scripts through different versions of perl.
unfortunately, you can't use the "shebang" in the beginning of your scripts in windows as you could do on unix systems.
I currently use Strawberry Perl as my primary Perl distribution. However, I have some applications that make Perl calls through cygwin. These generally fail because they are calling the version of Perl that was packaged with cygwin, and only looking in cygwin's lib folders. How can I modify my cygwin environment to call Strawberry Perl (and use the C:/strawberry/perl/lib dirs) instead?
If you remove Perl from cygwin using the setup program it will use Strawberry Perl by default.
If you are unable to remove Perl from cygwin, you can create a symbolic link to the Perl executable from Strawberry.
From a cygwin shell, use the following set of commands:
$ mv /usr/bin/perl /usr/bin/perl-cygwin
$ ln -s /cygdrive/c/strawberry/perl/bin/perl.exe /usr/bin/perl
This is assuming you used the default Strawberry Perl installer. Update your perl.exe location accordingly if you have it installed somewhere else.
Check to make sure the link is working properly by checking the Perl version:
$ perl -v
It should say This is perl, (version) built for MSWin32-x86-multi-thread (or similar) and not built for cygwin-thread-multi-64int.
You can change your PATH to put the Strawberry directories first. Strawberry tries to be nice by putting its directories at the end of the PATH. If you installed from the .zip file, however, it didn't change the PATH at all.
You could move /usr/bin/perl, but that's a bad idea since it breaks when cygwin tries to update what it thinks is its perl. I just had that happen to me this week and used to happen to me on my Mac until I stopped playing with the system setup and installed my own stuff completely separate.
One good thing I can add is that if you get the right perl to come first in the path, it should handle site-specific CPAN modules you may have installed with strawberry perl running in a CMD shell.
"which perl" is your friend.
If you had trouble with this, you could set the PERL5LIB environment variable, but it shouldn't be necessary.
I still pass in DOS-style file paths as parameters into the perl script, i.e. "d:\data\myfile.txt", not "/cygdrive/d/data/myfile.txt". So oddly enough, this mix of path notation works:
bash> /cygdrive/d/scripts/myscript.pl d:\data\myfile.txt
Many of these are good solutions, but I rather take an easy one that I don't have to modify more than once.
All you need to do is add/modify a line in your .bashrc file.
# Prepend strawberry perl to cygwin's path
export PATH=/cygdrive/C/Tools/Perl/perl/bin:$PATH
source .bashrc file from your shell, (or start a new shell) and run your program.
source ~/.bashrc
perl script.pl
This is probably not a preferred solution, but you should be able to modify the #! line:
#!/cygdrive/c/strawberry/perl/bin/perl5.10.0
I always refer to an explicit location and installation of perl, rather than relying on what is in /usr/bin.
I have two scripts that I use to modify the first line of Perl scripts to whichever Perl is first in my path: rightperl hardcodes to the Perl that is first in my $PATH now, envperl will change the line to #!/usr/bin/env perl so the Perl to use is only picked at the time the script is invoked. Works really well under Cygwin (and from a Unix shell in general).
If you don't want to mess around with any paths or do anything permanent there is an easy TEMPORARY hack. Type "where perl" at Cygwin sh prompt. It will list all the Perl.exe it sees in PATH in their order of execution. Change the names of the ones you don't want to be seen that get listed before the perl you want to use. But DO remember to change them back when you are done or you might have a few problems down the road.
I don't have my cygwin machine nearby so I can't test this, but perhaps you can front-end the perl command with a script: go to /bin under cygwin and move the perl.exe there to something else like perl-org.exe, then set up a shell script that execs your other perl with the same arguments.