I'm new to Perl.
Running Fedora 16
I have installed Perl recently, after the installation, I checked via "perl -v",
I got the following lines:
/usr/bin/perl: line 19: use: command not found
/usr/bin/perl: line 20: use: command not found
/usr/bin/perl: line 23: my: command not found
/usr/bin/perl: line 24: my: command not found
/usr/bin/perl: line 25: my: command not found
/usr/bin/perl: line 28: syntax error near unexpected token `('
/usr/bin/perl: line 28: `my %list=();'
Can I know why is it so?
Thank you.
That output is the output of a Perl script being executed by a bourne shell instead of perl.
perl is very funky on your setup. Maybe it has been accidentally replaced? Maybe you have an alias named perl? (What does type perl output?)
I had exactly the same problem.
Finally it was some so silly as that I had a blank space before the first line: #!/usr/bin/perl
Then, that line was ignored and the script was being interpreted by bash insted by perl.
I hope it helps to someone.
I'd be very surprised if there is a unix-like system which ships without perl. I'm not surprised that there are problems if more than one version are installed over each other.
If you have to use that system and can't start over, try installing it in some other location like /opt
Does #!/usr/bin/perl exists in your script at the begining?
I think its trying to run the script through the shell instead of perl, Check whether the script is using the encoding character UTF8 and finally try to invoke perl explicitly using the command perl filename.
Try to login with ROOT and try the same
Try the below command
which perl
You should get output as /usr/bin/perl
Related
I have given a perl script file executable permission on a Unix based system, but when I try to execute the file I get a "command not found" error. I have #!usr/local/bin/perl at the start of the script file.
At the top of your script, replace the #!usr/local/bin/perl with #!/usr/bin/perl notice the root '/' prior to the usr/
And you can try perl <filename> keyword to run the file instead of ./<filename>, using perl keyword should run the script regardless of the shebang line at the top of your script.
replace your first line #!usr/local/bin/perl with #!usr/bin/perl(which is called Shebang). Then you can run the file with perl <Path To File>.
I have a Perl program but when I am trying to run it, it's throwing the error
*****BEGIN: command not found
+ our =/prod/home01/appl/psoft/epmapp/batch/lib
/prod/home01/appl/psoft/epmapp/batch/bin/FileTransfer.pl: line 4: our: command not found
+ push #INC,
/prod/home01/appl/psoft/epmapp/batch/bin/FileTransfer.pl: line 5: push: command not found
/prod/home01/appl/psoft/epmapp/batch/bin/FileTransfer.pl: line 6: syntax error near unexpected token `}'
/prod/home01/appl/psoft/epmapp/batch/bin/FileTransfer.pl: line 6: `}'*****
I think the error is due to the fact that its trying to run the script via the shell instead of via perl. I have checked all the basic things, like there is no extra line before the she bang in my script. But still i am not able to figure out what the exact prob is.
Here is the start of our code:
#!/usr/bin/perl
BEGIN {
our $lib_path="/prod/home01/appl/psoft/epmapp/batch/lib";
push #INC, $lib_path;
}
I am using Red Hat Enterprise Linux Server release 5.9 environment.
Clearly it is interpreted as bash script. If shebang line is exactly as you pasted it, then it must be something wrong with perl binary. Don't you try to run it invalid way e.g. with "bash test.pl", or "source test.pl" from shell? Anyway the code is syntactically correct.
dtpwmbp:~ pwadas$ cat test.pl
#!/usr/bin/perl
BEGIN {
our $lib_path="/prod/home01/appl/psoft/epmapp/batch/lib";
push #INC, $lib_path;
print $lib_path . "\n";
}
dtpwmbp:~ pwadas$ bash test.pl
test.pl: line 3: BEGIN: command not found
test.pl: line 4: our: command not found
test.pl: line 5: push: command not found
test.pl: line 6: syntax error near unexpected token `}'
test.pl: line 6: `}'
dtpwmbp:~ pwadas$ ./test.pl
/prod/home01/appl/psoft/epmapp/batch/lib
dtpwmbp:~ pwadas$
If you can't stop the perl script being executed as a shell script, then adding the magic lines
eval 'exec /usr/bin/perl -S $0 ${1+"$#"}'
if 0; # not running under some shell
below the shebang might help.
I have observed that there are two ways of executing a perl program:
perl test.pl
and
./test.pl
What is the exact difference between these two and which one is recommendable?
I will rephrase slightly what other answers stated.
The first case will run the program called "perl" - presumably, a Perl language interpreter, and pass the value "test.pl" to it as the first parameter. Please note that this will do one of 3 things, depending on what "perl" is and what "test.pl" is:
If "perl" does not exist as an executable in your $PATH or a shell alias (check by running which perl), your shell will try to find a non-existing executable, and fail with perl: Command not found error.
If "perl" is an executable in your path (or a shell alias) that is NOT actually a Perl interpreter program, that will get executed instead. As example, try this in csh:
alias perl echo
which perl # Will print "perl: aliased to echo"
perl test.pl # Will print "test.pl". NOT what you intended!
unalias perl
This will execute your "perl" alias and simply echo the word "test.pl"
If "perl" is an executable in your path that IS a real perl interpreter, it will pass "test.pl" to it as a first parameter. In that case, Perl interpreter will treat this parameter (as it doesn't start with a "-") as the name of a file containing Perl code to execute and try to read the file in, compile it as Perl code and execute it.
Note that, since the program being run is actually "perl" and "test.pl" is just a text file being read in, "test.pl" does NOT need to have the "execute" Unix file permission.
The second case, shell will try to find a file called "test.pl" in your current directory, and - if it exists AND is executable - try to execute it as a program.
If the file does not exist OR if the execute bit on it is not set, the shell will fail with "command not found" error.
If the file has the execute bit set, shell (or actually process loader in Unix kernel) will try to execute it. The rules by which Unix executes a given executable file is governed by the first 2 bytes of the file, aka "magic number".
For a VERY good in-depth coverage of how magic numbers work, see "How does the #! work?" question on SO.
In a special case where the "magic number" is "#!" (aka "shebang"), the loader will read the first line of the file, and treat the contents of that line (sans the first 2 bytes) as a command to run instead of the given executable file; and append the path to the executable file as one more parameter to the command it read from shebang line. As examples:
if "test.pl" is a text file with a first line of #!/bin/sh -x, the kernel will execute /bin/sh -x ./test.pl.
if "test.pl" is a text file with a first line of #!/usr/bin/perl, the kernel will execute /usr/bin/perl ./test.pl.
if "test.pl" is a text file with a first line of #!perl, the kernel will execute perl ./test.pl.
if "test.pl" is a text file with a first line of my $var = 1; (or any other first 2 bytes it doesn't know what to do with), it will either error out or (at least on RedHat Linux) will pretend that there was an implied #!/bin/sh shebang and try to execute the file as Bourne Shell script. Which will of course fail since it was Perl code, not shell script
In the first case you are starting the perl interpreter and asking it to use your file and run it.
In the second case you are asking your shell to execute your file. This requires that the file starts with
#!/<path to perl>/perl
and that the file has the execute bit set.
The best method to use is the one that fits your usecase the best.
The first one will always run the script as the perl code.
The second one will do it only in case the perl is specified in she-bang. Otherwise it will run it as shell code or whatever is specified in she-bang (if there is no she-bang at all it will run as current shell code).
The first one will be executed even noexec mount option is enabled.
The second one will fail in that case.
The same stuff with execute bit. The first one will work if +x isn't setted, the second will fail.
The first executes the program using the perl that is found first in your $PATH. The second uses whatever shebang line in the program says.
If u set the executable permissions to the file , then you can run the file by ./ or else run using perl filename.pl
perl test.pl
Specify to the shell that you want the current Perl executable (as is found in your $PATH) to execute the test.pl file that is located in your $PATH.
Run which perl to quickly see what version of perl is the default
Run echo $PATH to see where the '.' (current directory) is. ALL directories BEFORE the '.' will be checked FIRST for the test.pl file! Use ./test.pl instead so the shell looks in the current directory only...Unless you want it to hunt in the $PATH for the test.pl file.
./test.pl
Specify to the shell that you want the test.pl file, in the current directory, to be run by the executable as specified inside the test.pl file at the line with the she-bang (line that starts with #!).
I am executing my perl files in a batch. I am pasting all the name of the perl file in a batch file and executing it. I am giving a small demo of the file.
The batch file /10BT_run1.Amset contains:
Perl ../tools/test_driver_multi_aid_sequential.pl e2_h/l2_mode/set_bwprf #this is line 4 of the batch file
I am getting error like
Bareword found where operator expected at ./10BT_run1.Amset line 4, near "/tools /test_driver_multi_aid_sequential"
(Missing operator before test_driver_multi_aid_sequential?)
Bareword found where operator expected at ./10BT_run1.Amset line 4, near "/l2_mode/set_bwprf"
(Missing operator before et_bwprf?)
You are somehow executing the batch file (./10BT_run1.Amset) using perl instead of cmd.
you can run the perl files as argument to perl interpreter
perl "../tools/test_driver_multi_aid_sequential.pl e2_h/l2_mode/set_bwprf"
if you are going to use " in between the arguments separate those as escaping sequence like
\"
It will avoid the error that you have mentioned
I have a long-ish Perl script that runs just fine, but always gives this warning:
Can't find string terminator '"' anywhere before EOF at -e line 1
I've read elsewhere online that this is because of a misuse of single or double quotes and the error generally stops the script from running, but mine works. I'm pretty sure I've used my quotes correctly.
Is there anything else that could cause this warning?
EDIT:
I'm running the script via TextMate, which may be spawning a new Perl process to run my script.
I actually get the error when I run simple scripts as well, like this one:
#!/usr/bin/perl -w
use strict;
use warnings;
print "Hello world.";
Yes, you are right, your script does that in TextMate when I try it too.
Simple solution: don't run it using TextMate; just use the command line:
cd Projectdirectory
chmod +x myscript.pl
./myscript.pl
Hello world
More complex solution: tell TextMate that their application is broken and wait for them to fix it. The error is coming from some other Perl script that TextMate is invoking. Even a completely blank file run as Perl in TextMate fails with this error.
-Alex
The "at -e line 1" bit means it's coming from a one-liner. I suspect your long script is somewhere starting a separate perl process (possibly indirectly), and that perl is what is giving the error (and not doing whatever it is supposed to do.)
Start the debugger by doing
perl -d ./youscript.pl
Then keep pressing n[ENTER] (or just ENTER after you press n once) until you see the warning - the line that was just executed is your culprit. n stands for the next debugger directive btw.