I have perl express 2.5 loaded on my server. I would like to be able to run my perl scripts using a command line so they can be scheduled rather than manually bringing up the script in Perl Express and clicking on the run command. Is there a way to execute the script from a command line using this version of Perl or do I need to download a newer or more robust version of the Perl Engine.
You need to export the Perl interpreter (usually named perl) to your path. Then you can simply do
perl path/to/script.pl
In UNIX-based systems you are also able to run the scripts directly if you prepend
#!/usr/bin/perl
to the scripts and give them executable permissions (you might need to replace /usr/bin/perl with the path to your Perl interpreter).
According to the documentation:
Perl Express is not tied to a specific Perl port and should work with any build for Windows.
and the system requirements:
Windows 98/Me/2000/XP/2003, Perl Interpreter
So you, presumably, have a separate Perl distribution already installed somewhere. That should have a perl.exe executable that you can use to run your script.
You just need to give perl command and the path of your perl script.
example :
D:\Project\dir>perl <path_of_perl_script .pl>
Related
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'm trying to build a perl package (module + scripts).
My Makefile.PL has the following to include my script
EXE_FILES => [
'bin/somescript1',
],
But after installing the script, it adds the following to the beginning of the installed script.
eval 'exec /usr/bin/perl -S $0 ${1+"$#"}'
if 0; # not running under some shell
Why does it do this and can I make it not include that?
When ExtUtils::Makemaker installs your scripts, it modifies to the shebang line to use the path to the perl you used to build the distribution. That way, when you call the script, it uses the same perl that you used to install the dependencies.
Additionally, it adds that exec line. If, for some reason, the system starts your program in the shell instead of perl, the exec switches it to perl.
Leave it alone. This only helps you.
However, if you want to override it, you have to override the parts of Makemaker that install programs. If you want to cut off your arm, you'll have to find out how to do that yourself. It's all in the Makemaker docs.
You should not worry about those lines. It's a way to make your script runnable with both Perl and the shell, making it super-portable.
If you set the shebang line to #!/usr/bin/env perl you can exploit a bug in ExtUtils::MM_Unix and the eval line isn't added on install. This wil break if the installing host does not have a working /usr/bin/env
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.
What is the most cross platform way to execute a pPerl script from ant?
Windows does not like the Perl script as the executable. Is there any way other than just running Perl using an OS specific executable and passing the Perl script in as an argument?
Have you considered the ant <exec> command? You can use the os attribute to specify which operating system to use.
The catch would be that you would need a specific call for each known operating system the Perl script will be used on. Its probably safer to do an os check anyway.
Have you tried creating a custom Ant target for calling Perl (let's call it call-perl-script), and the implementation of that task switches to another subtask based on the OS (like call-perl-script-windows, call-perl-script-osx, etc.)?
Something based on this previous question, or this or this?
Windows does not like the Perl script as the executable.
Either you configure windows to execute .pl files (help ftype, help assoc)
ftype PerlScript=perl.exe %1 %*
assoc .pl=PerlScript
or you run the script through pl2bat (happens automatically if you use ExtUtils::MakeMaker to install script). If you use pl2bat, please examine the resulting file and make sure you're satisfied with the results.
you could also use PAR/pp to create an .exe
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.