Maybe it's dumbest question in the world, but I seriously have problems with it and could use help. I am trying to run perl script on linux. It's a simple text editing script, nothing fancy. I googled for it and I found that I had to chmod +x it and then just run myscript.pl in the console. Since it's supposed to modify a text file I did myscript.pl > myfile.txt after chmoding it
But it doesn't work. I get: bash: perl myscript.pl: command not found
Unless myscript.pl is in your path you will need to specify the current directory.
$ ./myscript.pl
You can check if the current directory is in your path with $ echo $PATH. If you're frequently using this script you can put it in the path by moving it to a directory that's part of your path, usually ~/bin.
Or by adding the current directory to the $PATH environment variable. Check the documentation for your shell for instructions.
Can you post the first few lines of your script?
Specifically, if you have #!/usr/bin/perl are there any typos on that line, extra spaces, etc.?
Also do a ls /usr/bin/perl (or whatever is on that line) to make sure it's actually there.
It doesn't look like perl is installed on your Linux machine. Do you get the same thing when you try this: # perl -e 'print "hi";' ?
As Chirael said, it sounds like your shebang line (the directive at the top of the file, that tells the shell how to run the script) is invalid somehow. You can bypass the shebang line entirely by invoking your script as:
perl myscript.pl > myfile.txt
You also don't need to set the script's executable bit, as with this method of invocation, you are only reading the script, not executing it (from the shell's perspective).
According to this thread, it could be from different representation of the new line.
Have you written the script on a windows box and copied over to your linux box?
What is your text editor?
I had the same issue, and traced it to DOS line endings (^M). Running dos2unix on the .pl file fixed the issue.
Please use,
./myperl.pl > outfile.txt
to give the current directory path
thanks
Related
I have just added this script to PATH variable, but it does not work.
I need to use it in any directory as:
perl script.pl SOME ARGUMENTS
I have windows 7 Ultimate.
Thank you for advices!
While the system is using PATH to find the program to run, the system is executing perl, not script.pl.
Either tell perl to search PATH for the script,
perl -S script.pl SOME ARGUMENTS
Or launch the script directly.
script.pl SOME ARGUMENTS
Windows will use file associations to determine how to launch the file in the latter case.
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 have a command
my $output = `somecommand parm1 parm2`;
When I try to run this Perl script I get the message
Can't exec "somecommand" at .....
It seems it is not seeing anything past the first space in between the backticks. I have a friend who runs this in a different environment and it runs fine.
What could I have in my environment that would cause this? I am running Perl v5.20 but so is my friend.
Perl's not ignoring the command parameters, it's just mentioning only the part of the command that it has a problem with -- it can't find somecommand
Whatever your somecommand is, it's not a shell command and it's not in a directory listed in your PATH variable
Change PATH to add its location to the end and it will work for you. You can do that system-wide or you dan modify it temporarily in your Perl code by manipulating $ENV{PATH} before you run the command
I was sent a perl script over mail and asked to run it .I placed it on my local drive as is but when I tried to run the script it shows me
/usr/bin/perl^M: bad interpreter: No such file or directory
I checked and usr/bin/ does have perl in there .I am not sure what is wrong.I checked a bit and looks like I am missing some spaces or something ..I tried adding those at the end of
usr/bin/perl and at the end of the file but that didnt help either.
I even tried to use dos2unix
dos2unix oldfile newfile
'dos2unix' not found.This is on MacOSX.
Might I also mention that I am sshing into my mac using my windows machine at home.
You're on the right track. Your script has DOS style newlines at the end, which is not supported by your kernel.
The solution is to use something to convert the DOS newlines to Unix style. dos2unix would presumably work if you had it, so use something else equivalent.
In the absence of dos2unix, you can use tr (on Mac OS X) to strip the DOS / Windows new-lines:
tr -d '\r' < old.pl > new.pl
This will solve the "bad interpreter" issue.
"Can't locate Gpu.pm in #INC" is a different issue. Either you don't have Gpu.pm installed on your Mac (or whichever computer on which you are running this, I'm confused by your comments) or it's not in your include path. I don't who what that script is or what it does. A quick look on http://search.cpan.org/ revealed nothing.
If you can get that Perl module (presumably from whoever supplied oldfile), you'll have to ensure it is in #INC.
Do this in vim:
:%s/^M//g
save the file and try running it again
execute: vim
when vim opens go to command mode by hitting the escape key .... at the command prompt (:) type: %s/^M//g. This will remove all "^M" characters from the file.
dos2unix in Perl:
perl -pi -e 'tr/\r//d' file.txt
I have this perl script that I need to distribute to my coworkers who want to run the script from anywhere in the unix environment. What can I do on my part to make running this PERL script easy for them? For example, they can just have the PERL script somewhere in their directory and run just typing
./xyz.pl ttt.conf
with no path declared (like /home/abc/bin/ddd/xyz.pl ttt.conf).
The way I used to do it is add a "bin" directory in your home directory, and add it to the $PATH variable.. then you can add any script you want to use to that directory.
I am no longer familiar with the exact syntax, but something like:
in .bashrc:
$PATH = ( $PATH , $HOME/bin )
Then place the script in /home/user/bin (assuming $HOME == /home/user). When you reload the shell, it will be usable like any normal command/program.
ETA: See robert's comment below on syntax. Also, to allow your co-workers to use a script of yours, you can simply use a hard-coded path, such as /home/patrick/bin.
Put the script in /usr/local/bin (or anywhere else in $PATH). Your sysadmin may have to help you.
The technique I use is:
#!/usr/bin/env perl
This is a common way of getting the command interpreter to find Perl without either (a) moving the file, or (b) declaring the explicit path for Perl in the shebang.
It's mentioned under portability at: http://en.wikipedia.org/wiki/Shebang_(Unix)
You all are kind of right... but that perl script can sit in your path till the cows come home... and it ain't gonna run... until you set the executable bit....
:bin localadmin$ ./perlextip
-bash: ./perlextip: Permission denied
:bin localadmin$ chmod +x perlextip
:bin localadmin$ ./perlextip
Exit 0! Yeehaw.
Also, it should be noted that it need not be IN your path.... You can just call it by the full path, preceeded with a period and a slash, to execute it..
:/ localadmin$ ./ServiceData/UNIX/bin/extip
Exit 0! Yeehaw.
You can also create an alias for such a command in your ~/.bash_profile, or the such, which will let you make a system-wide shortcut of sorts, and you can even throw in a sudo, or the like, if you were so inclined... Then just call that "extip" by name anywhere, you'll be prompted for a password and, all will be well in the world.
alias extip='sudo ./ServiceData/UNIX/bin/extip'