I found this piece of code in perl
system("zip $ZIP_DEBUG -r -9 itvlib.zip $include $exclude");
However I don't understand how it is working. I mean system() is used to fire 'system' commands right ? So is this 'zip' command used here a 'system' command ?
But I tried firing just the following on the command prompt;
zip $ZIP_DEBUG -r -9 itvlib.zip arg1 arg2
It didn't work !
it gave the following error:
'zip' is not recognized as an internal or external command,
operable program or batch file.
Well this shouldn't have happened, since the command seems to use 'zip' as a system command. So this makes the command 'zip' mysterious
Can you please help me to understand this command with all its parameters?
It's probably not working since you're not replacing things like $ZIP_DEBUG with their equivalent real values. Within Perl, they will be replaced with the values of the variables before being passed to the system call.
If you print out those Perl variables (or even the entire command) before you execute that system call, you'll find out those real values that you need to use. You can use the following transcript to guide you:
$ perl -e '
> $ZIP_DEBUG = "xyzzy";
> $include = "inc_files";
> $exclude = "exc_files";
> print "zip $ZIP_DEBUG -r -9 itvlib.zip $include $exclude";
> '
zip xyzzy -r -9 itvlib.zip inc_files exc_files
For details on how system works, see here. For details on what zip needs to function, you should just be able to run:
man zip
from a command line shell (assuming you're on Linux or its brethren). If, instead, you're on a different operating system (like Windows), you'll have to figure out how to get the zip options out. This may well be as simple as zip -? of zip -h but there's no guarantee that will work.
If it's the same as the Info-ZIP zip under Linux (and it may be if you have the -9 and -r options and your exclude variable starts with -x), then zip -h will get you basic help and zip -h2 will give you a lot more.
system("zip $ZIP_DEBUG -r -9 itvlib.zip $include $exclude");
is running a program named zip (probably zip.exe) somewhere on the path. $ZIP_DEBUG, $include, and $exclude are Perl variables that are interpolated into the command line before the command is run.
If the system call works in the Perl script, but zip -? gives the 'zip' is not recognized as an internal or external command, operable program or batch file error, then the PATH of the Perl script must be different than the PATH in your command prompt. Or, there might be a zip command in the current directory when Perl executes the system command. (In Windows, the current directory is an implicit member of your PATH.)
To see what the PATH is for the Perl script, you can add a print "$ENV{PATH}\n"; before the system command. To see what the PATH is in your command prompt, type PATH.
Yes, zip is a system command. The variables $ZIP_DEBUG and such are perl variables that are interpolated to the command before launching zip.
To debug what the actual call is, try adding:
print("zip $ZIP_DEBUG -r -9 itvlib.zip $include $exclude\n");
See perldoc for details on system.
Related
I have the following Perl script. I am trying to run it in Windows 7 using ActivePerl:
#!c:\Perl64\bin\perl.exe -w
use strict;
my $mp3splt_exe = 'c:\Program Files (x86)\mp3splt\mp3splt.exe';
my $mp3splt_args = '-o "#n #f" -g "r%[#o #N]" -f -t 6.0';
print #ARGV;
my $filename = $ARGV[0];
print "$mp3splt_exe $mp3splt_args $filename\n";
(as you can see, I am trying to create a wrapper for mp3splt :-) )
When I run it like this:
C:\Program Files (x86)\mp3splt>run_mp3splt.pl a
I get this:
Use of uninitialized value $filename in concatenation (.) or string at C:\Program Files (x86)\mp3splt\run_mp3splt.pl line 12.
c:\Program Files (x86)\mp3splt\mp3splt.exe -o "#n #f" -g "r%[#o #N]" -f -t 6.0
So, first of all, when I print #ARGV, nothing gets printed, and second of all, when I assign $filename = $ARGV[0], $filename is undef, so I get the warning.
So... what am I doing wrong? Why isn't the commandline parameter being passed to the script?
As others have pointed out perl blah.pl asdf works, while blah.pl asdf fails. This is because when you run the perl script directly, Windows realizes it must call perl, and uses the rule perl "%1", which only passes the script name to perl, not any of the parameters.
To fix this, you have to tell windows to use the rule perl "%1" %*
How to do that can be a little tedious:
Option 1
According to perlmonks, you should be able to use assoc and ftype on the commandline. In fact, if you type help ftype, it tells you how to setup perl:
assoc .pl=PerlScript
ftype PerlScript=perl.exe %1 %*
To run assoc requires cmd run as administrator on Window 7.
However, this didn't work for me. Windows ignored the association. I had to modify the registry. This may be due to the misguided advice to run the Default Programs utility on Win 7, which lets you specify the program to use for given file extensions. Unlike XP, this will not allow you to specify multiple command options (to be used in the right-click menu) -- it will only allow you to specify the program that is used when you double-click on a file (or run foo.pl from commandline).
Option 2
Modify the registry: HKEY_CLASSES_ROOT
If you've used the assoc/ftype commands, you may have entries for perl or PerlScript. As I said earlier, these will be ignored. Look for pl_auto_file, and drill down to the command:
HKCR\pl_auto_file\shell\open\command
Here the (Default) should be set to something like: "C:\Perl\bin\perl.exe" "%1"
Add the missing %* on the end of that and you should be good to go: "C:\Perl\bin\perl.exe" "%1" %*
No reboot necessary.
Option 3
If you're lazy and trusting, you can try using this as a reg file, and importing it into your registry:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\pl_auto_file\shell\open\command]
#="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"
This should be sufficient to make blah.pl asdf work.
I've had the problem that if I executed on Win7:
perl myprog.pl a b c
the program got the parameters (in #ARGV) correctly, but if I executed:
myprog.pl a b c
the program would NOT receive the parameters.
I searched the web for a solution and soon found that it was no ActiveState perl problem but more likely a filetype association problem in Windows (Win7), (thanks to the PerlMonks website).
However all solutions changing the
assoc .pl=Perl
and the
ftype Perl="C:\Perl\bin\perl.exe" "%1" %*
did not solve the puzzle for me. I did notice that the assoc .pl was not used somehow because if I added assoc .plx=Perl and renamed my program to myprog.plx
myprog.plx a b c
worked perfectly !
So then I read this problem on the Microsoft forum were the Win7 "feature" Default Programs was mentioned, I found the solution to my problem:
Open Default Programs by clicking the Start button , and then click "Default Programs".
Select "Associate a file type or protocol with a program" and select ".pl" and click on "Change program". There was already a Perl Command Line Interpreter specified as Recommended Programs but instead I clicked on Browse and selected the Perl.exe myself. After closing the "Associate a file type ..." screen,
myprog.pl a b c
executed like a charm, all parameters were correctly retrieved by my program.
Hope that helps...
Perl ARGV problem solution in Windows 8.1:
HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command =
"C:\Perl\bin\perl.exe" "%1" %*
No re-boot needed.
I'm pretty sure Windows 7 doesn't understand the shebang line. What happens if you run this with perl run_mp3splt.pl a?
I can use the if (-e $file) in perl script to tell if a file exists in linux or not.
I can run p4 fstat $file in linux to tell if a file exists in perforce depot.
But how do I use perl script to check if a file is in perforce depot?
You can run a command from a Perl script with the backtick operator:
`p4 files $file`
This will work as a truthy check to see if a file exists in Perforce:
if (`p4 -F %depotFile% files "$file"`)
Note that this requires you to be logged in to the Perforce server before you run the script (if you can't connect you'll always get "false" from the above condition).
Based on the question asked, it appears that you could run the p4 command using Perl's system(), or the exec() method, or as described above using the "backticks" operator.
The backtics operator will allow you trap STDERR and STDOUT from the command, so that you can use it for whatever.
The other two will attempt run the command and give return values accordingly, as described in perldoc -f exec
So, typically what can be done is a command like:
p4 files $file
Followed by
echo $?
The second command will get you the exit status of the last shell command.
When using backticks you can also try these:
Windows: command-to-execute 2>NUL
Linux / OSX: command-to-execute 2> /dev/null
These will suppress STDERR and give you the output only. If you use a "1" instead of a "2" you will suppress STDOUT and get the error only.
Finally, if you want both, you can use:
Windows / Linux / macOS: command-to-execute 1>2&
This will concatenate STDOUT and STDERR.
So in short, you use Perl to run any existing program on any operating system, and there are multiple ways to process the result of that.
Running Lubuntu -
Beginner Perl programmer
Script is XXX.pl located at ~/projects/XXX/XXX.pl
First line is the shebang
#!/usr/bin/perl
Permission to run is set to Anyone.
In directory ~/projects/XXX, the command
~/projects/XXX$ perl XXX.pl
works as desired, but the command
~/projects/XXX$ XXX.pl
Fails with XXX.pl: command not found
What am I missing ?
The two usual options to execute your Perl script are:
perl XXX.pl
or
./XXX.pl
Both ways assume that your current working directory contains the script XXX.pl, otherwise it won't work.
As already pointed out by jm666 in the comments, you can usually not execute a program or script from your current working directory without prepending ./, primarily because of security reasons. Now, you may wonder why it's necessary.
Explanation:
Your shell uses the contents of an environment variable called $PATH to find out about where external commands (non-builtin programs) are located in your filesystem. If you want to see what's in $PATH, just type the following in your shell:
echo $PATH
Now you can see that the $PATH variable does NOT contain your current working directory. The consequence is that your shell is not able to find the program XXX.pl. By prepending ./ you instruct the shell to execute the program which comes after.
But there are two requirements if you want to execute your Perl script with ./script.pl:
The script has to be executable (check with ls -l)
The first line (shebang line) has to be #!/path/to/your/perl because your shell needs that information to find the perl interpreter in order to run your script
However, #1 and #2 are NOT required when you execute your script with
perl XXX.pl
because it invokes the perl interpreter directly with your script.
See how to make Perl scripts executable on Linux and make the script itself directly executable with chmod for some more details.
Can the script be found?
Is . in your path? If it's not, add it to your path, or use ./XXX.pl instead of XXX.pl.
Can the script be executed?
Do you have execute permission to the file? Fix using chmod u+x XXX.pl.
Is the interpreter correct?
which perl will tell you which interpreter is used when you use perl XXX.pl. That's the path that should be on your shebang (#!) line.
I am using mr on Windows and it allows running arbitrary commands before/after any repository action. As far as I can see this is done simply by invoking perl's system function. However something seems very wrong with my setup: when making mr run the following batch file, located in d:
#echo off
copy /Y foo.bat bar.bat
I get errors on the most basic windows commands:
d:/foo.bat: line 1: #echo: command not found
d:/foo.bat: line 2: copy: command not found
To make sure mr isn't the problem, I ran perl -e 'system( "d:/foo.bat" )' but the output is the same.
Using xcopy instead of copy, it seems the xcopy command is found since the output is now
d:/foo.bat: line 1: #echo: command not found
Invalid number of parameters
However I have no idea what could be wrong with the parameters. I figured maybe the problem is the batch file hasn't full access to the standard command environment so I tried running it explicitly via perl -e 'system( "cmd /c d:\foo.bat" )' but that just starts cmd and does not run the command (I have to exit the command line to get back to the one where I was).
What is wrong here? A detailed explanation would be great. Also, how do I solve this? I prefer a solution that leaves the batch file as is.
The echo directive is executed directly by the running command-prompt instance.
But perl is launching a new process with your command. You need to run your script within a cmd instance, for those commands to work.
Your cmd /c must work. Check if you have spaces in the path you are supplying to it.
You can use a parametrized way of passing arguments,
#array = qw("/c", "path/to/xyz.bat");
system("cmd.exe", #array);
The echo directive is not an executable and hence, it errors out.
The same is true of the copy command also. It is not an executable, while xcopy.exe is.
I wrote a perl script which uses some linux commands (grep, ls etc..). I can successfully run this from Cygwin or Linux. I want this task to be run periodically on a Windows Server which has Cygwin installed. I was planning to use Windows task scheduler. But I am not sure how to specify in a Windows bat file, that my perl script needs to be called in Cygwin mode?
EDIT: I tried the command by Glenn. When I tried running the perl script, it doesn't seem to respond. So I tried with a sample script: test.sh, which has the following two lines:
ls -l
cd ..
Here is the screen capture of what I am getting:
I'm not a great fan of cygwin and personally prefer natively compiled versions of the GNU tools, e.g. GnuWin32.
I also wonder why you would be using grep, ls etc. from a Perl script. Most of that functionality can be handled natively by Perl and this usually results in much better portability and robustness.
Perhaps (untested): c:\cygwin\bash.exe -c /path/to/your/script.pl
UPDATE:
The last error message reveals one problem: your script is a DOS format file (CRLF line endings), while cygwin looks for UNIX format (LF line endings). The stray carriage returns at the end of each line is the problem. For example, there's no directory named "..\r"
Use a text editor where you can specify the line endings to use. In a bash shell, you can do dos2unix test.sh
The ls error indicates that /bin and /usr/bin are not in your bash environment's $PATH -- is that true?
Just add cygwin to your path before running perl. For example, I often run find in a dos shell, but get the rather horrible message FIND: Parameter format not correct. Bah! Instead I have to run find via a dos cmd file cyg.cmd:
c:> find . -iname interesting.txt
FIND: Parameter format not correct
c:> cyg find . -iname interesting.txt
sub/sub/interesting.TXT
c:> type bin\cyg.cmd
setlocal
PATH=c:\Progs\Cygwin\bin;%PATH%
%1 %2 %3 %4 %5 %6 %7 %8 %9
endlocal
The important bit here is the PATH=c:\Progs\Cygwin\bin;%PATH%.
BTW, I much prefer the cygwin versions of the tools rather than their MinGW equivalents—the environment is much closer to Mac/Linux, and portability is important after all.
You run cygwin bash, but you still have to setup your PATH. Unless you set it in your profile, but initialize the profile then with bash -i.
Either specify the full path to cygwin commands needed, like /bin/ls, /bin/grep,
or add c:\cygwin\bin and maybe other paths to your PATH beforehand.
2nd preferred. Like
schedule.bat:
PATH=C:\cygwin\bin;%PATH%
sh -c ./schedule.sh
schedule.sh:
#!/bin/sh
ls ...
grep ...
perl ...
schedule.sh gets the environment with the PATH from the parent process sh.exe, which inherits it from your bat.
Seperating shell scripts from batch files just for easier testing. You can call most cygwin programs from cmd.exe also.
You cannot set /usr/bin in your DOS PATH, DOS will not have a c:/usr directory. And it only works if you are in C: