I tried to run script in git bash command line and I saw:
"use: command not found"
When I changed sh file from
'./clean_translations.pl' to 'perl ./clean_translations.pl'
After that script works.
I have win 8.1. Path is as in other PC (win 7).
What should I change to works without 'perl'?
Edit: echo $PATH:
/c/Users/PBI/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/PBI/bin:/c/usr/bin:/c/strawberry/c/bin:/c/strawberry/perl/bin:/c/straw
berry/perl/site/bin:/c/strawberry/c/lib:/c/strawberry/perl/site/lib:/c/strawberr
y/perl/lib:/c/Program Files (x86)/ActiveState Komodo IDE 8:/c/instantclient_12_1
:/c/Program Files/Java/jdk1.8.0_91/bin:/c/Program Files/Java/jre1.8.0_91/bin:/c/
Program Files (x86)/Intel/iCLS Client:/c/Program Files/Intel/iCLS Client:/c/Wind
ows/system32:/cmd:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/Window
sPowerShell/v1.0:/c/Program Files/Intel/Intel(R) Management Engine Components/DA
L:/c/Program Files (x86)/Intel/Intel(R) Management Engine Components/DAL:/c/Prog
ram Files/Intel/Intel(R) Management Engine Components/IPT:/c/Program Files (x86)
/Intel/Intel(R) Management Engine Components/IPT:/c/Program Files (x86)/ATI Tech
nologies/ATI.ACE/Core-Static:/c/Program Files (x86)/GitExtensions:/bin:/mingw64/
bin:/usr/bin/vendor_perl:/usr/bin/core_perl
You need to use a shebang.
Add this as the first line of the script:
#!/usr/bin/env perl
This conveys that the script should be run using Perl interpreter.
If you are running the script on windows shebang is not parsed. The file extension(.pl) is used to decide the interpreter. In a bash shell shebang is necessary.
Related
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've installed ActiveState Perl on my new Windows 10 PC. I've installed the same exact version of Perl on several of my own PC's, and it's installed on 100's of other users' PC's in my company. Same exact install, created by me.
This is the first time trying this on Windows 10. The basic actions of double-clicking a Perl script (*.pl) in Explorer cause a console window to open and Perl to run the script.
Also, in Windows Command Prompt, I can type perl.exe script.pl, and the script runs fine. But, when I just type script.pl, nothing happens. No output, no errors, no perl.exe processes visible in Task Manager.
The first time I ran a Perl script (from Windows Command Prompt, I believe, using just the script.pl syntax), Windows popped up a window asking me what program I wanted to use to open this file. Perl was the default, and I clicked OK.
I've never seen that window in Windows 7 or 8, so I'm thinking it's something specific to Windows 10, and that it's the thing that's somehow preventing me from just typing script.pl. Because, when launching script.pl, I'm requiring the file associations to pick the right program, but when I type perl.exe script.pl, perl.exe is being launched directly. But, that Windows 10 "pick your default program" thing is getting in the way when running from the command prompt by messing up the file associations.
Not 100% sure why it works from Explorer, though, but I'm pretty sure that I need to clear that default program thing. I removed the registry entry for .pl files under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts, but that didn't help.
This seems to be a more generic problem with Windows 10, or possibly just my installation of it, or a Group Policy I'm not aware of.
The following commands (run in a Admin command prompt) work fine in Windows 8.1 but not Windows 10:
assoc .foo=Foobar
ftype Foobar=C:\WINDOWS\system32\foo.bat %1
echo #echo off > foo.bat
echo echo The filename is %1 >> foo.bat
echo hi > foo.foo
foo.foo
The result should be the output:
The filename is C:\WINDOWS\system32\foo.foo
But Windows 10 does nothing. It seems to only allow built-in apps to be associated in this manner, and not BAT scripts of downloaded/installed EXEs.
Turns out that Microsoft reversed the polarity of a Registry setting in Windows 10, and this is biting other Perl programmers too. The solutions is to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\InheritConsoleHandles to "0".
MSDN post here: https://social.msdn.microsoft.com/Forums/en-US/f19d740d-21c8-4dc2-a9ab-d5c0527e932b/nasty-file-association-regression-bug-in-windows-10-console
Make sure your PATHEXT environment variable has .pl in it.
Hello I'm trying to run a perl script on a Windows 64 bit. I'm getting the error like this :
/usr/bin/perl : bad interpreter : Permission denied
I have my perl script on my windows 64 bit C:\test\perlscripts\testperl.pl.
You probably saved the Perl script with DOS style line endings. The shell is looking for a file called /usr/bin/perl<CR>.
Save your files with Unix-style line endings. My .vimrc which I use with my natively compiled vim and gvim has:
set fileformat=unix
set fileformats=unix,dos
Check your editor's settings for the appropriate options.
To fix line endings in a particular file, use $ dos2unix filename.
You may not install Perl in default cygwin64 package. Please ensure that you have Perl at /usr/bin/perl.exe.
If it is not there, run setup-x86_64.exe again and select Perl interpreter.
I have a perl script exist in the follwoing path (/home/Leen/Desktop/Tools/bin/tool.pl)
Every time I want to run this tool I go to the terminal
>
and then change the directory to
..../bin>
Then I run the perl by writing
..../bin> perl tool.pl file= whatever config= whatever
The problem is that I want to run this perl script without the need to go to the bin folder where it exist . so I can run perl script from any directory and as soon as I enter shell
I went to the etc/environment and I wrote the follwoing
export PERL5LIB=$PERL5LIB:/home/Leen/Desktop/Tools/bin
But when I go to terminal and write the follwoing straight ahead without going to bin folder where tool.pl exist
>perl tool.pl file=... config=...
it says the file "tool.pl" does not exist???
The first argument to the perl program is the path to an executable file. These calls are equivalent:
:~$ perl /home/Leen/Desktop/Tools/bin/tool.pl
:~$ perl ~/Desktop/Tools/bin/tool.pl
:~$ perl ./Desktop/Tools/bin/tool.pl
:~/Desktop/Tools/bin$ perl tool.pl
:~/Desktop/Tools/bin$ perl ./tool.pl
etc.
In the shell the tilde ~ expands to your home directory, and ./ symbolizes the current directory. On *nix shells (including the various terminal emulators on ubuntu), the command prompt ususally is $ in nomal mode, # as root user and seldom %. > Is a secondary command prompt, e.g. when continuing a multiline argument, unlike cmd.exe on Windows.
The PERL5LIB variable determines where Perl looks for modules, not for executable files.
You can set a script as executable via chmod +x FILENAME. You can then call the script without specifying the perl program:
:~/Desktop/Tools/bin$ ./tool.pl
You can modify the PATH variable to change where the shell looks for executables. The PATH usually contains /usr/bin/ and other directories. You can add a directory of your own via
PATH=$PATH:/home/Leen/Desktop/Tools/bin
Add your directory at the end of the PATHes, so you don't overrule other programs.
If you want to set this permanently, you can add this line to the file ~/.bashrc (only for your user and only for the bash shell).
Then you can call your script from anywhere, without a full path name:
:~/foo/bar$ tool.pl
You should consider using a more specific command name in this case, to prevent name clashes.
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: