OS: WINDOWS
perl: strawberry perl
vim: gvim74 (can run perl and ag by useing :!perl ：！ag)
I use strsf.vim in VIM.
strsf.vim need ag or ack in background.
when I put ag.exe in system32 folder,strsf.vim works well.
the question is:
if I want to use ack instead of ag,
how can I make gvim know where the ack-standalone.pl is?
I have tried to put it in system32 , vim folder perl folder,neither worked
I also add perpath vim path to OS path ,nothing changed
I konw the ack-standalone.pl should run in perl ,
and I tried to use ：！perl ack-standalone.pl in vim，but some error occured as below
C:\windows\system32\cmd.exe /c (perl ack.pl)
Can't open perl script "ack-standalone.pl": No such file or directory
shell returned 2
Hit any key to close this window...
when I use a bat file :
#"C:\Strawberry\perl\bin\perl.exe" C:\Strawberry\perl\bin\ack-standalone.pl %*
it can works
what should I do if I want to use the ack-standalone.pl file in gvim ?
I solved it by using a ack.batfile,and put it in system32 folder which VIM can find it.
The content of ack.bat is
#"C:\Strawberry\perl\bin\perl.exe" C:\Strawberry\perl\bin\ack %*
I don't think it is a good solution, so if anyone have a better one ,please tell me.
Related
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 want my Perl scripts to behave just like any other executable (*.exe file).
When I double-click on myscript.pl I want it to execute instead of opening in a text editor.
I want to run myscript.pl instead of perl myscript.pl.
I really want to run myscript instead of myscript.pl.
I want to run program | myscript instead of program | perl myscript.pl.
I want to be able to run my script via drag & drop.
There are a number of changes you have to make on Windows to make all of
these things work. Users typically stumble upon things that don't work one at
a time; leaving them confused whether they've made an error, there's a bug in
Perl, there's a bug in Windows, or the behavior they want just isn't possible.
This question is intended to provide a single point of reference for making
everything work up front; ideally before these problems even occur.
Related questions:
How do I make Perl scripts recognize parameters in the Win32 cmd console?
Running a perl script on windows without extension
Perl execution from command line question
How can I read piped input in Perl on Windows?
Perl on Windows, file associations and I/O redirection
How do I create drag-and-drop Strawberry Perl programs?
Note: The actions below require administrative privileges. For
steps utilizing the command prompt it must be launched via "Run as
administrator" on Windows Vista / Windows 7.
Associate *.pl files with perl
Run the following commands at a shell prompt:
assoc .pl=PerlScript
ftype PerlScript=C:\bin\perl.exe "%1" %*
Replace C:\Perl\bin\perl.exe with the path to your Perl installation. This
enables you to run myscript.pl instead of perl myscript.pl.
Default install locations are:
ActivePerl: C:\Perl
Strawberry Perl: C:\Strawberry
Add .PL to your PATHEXT environment variable.
This makes Windows consider *.pl files to be executable when searching your
PATH. It enables you to run myscript instead of myscript.pl.
You can set it for the current cmd session
set PATHEXT=%PATHEXT%;.PL
To set it permanently (under Windows Vista or Windows 7)
setx PATHEXT %PATHEXT%;.PL
Under Windows XP you have to use the GUI:
Right-click My Computer, and then click Properties.
Click the Advanced tab.
Click Environment variables.
Select PATHEXT, then click Edit.
Append ;.PL to the current value.
Make I/O redirection work
I/O redirection (e.g. program | myscript) doesn't work for programs started
via a file association. There is a registry patch to correct the problem.
Start Registry Editor.
Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
On the Edit menu, click Add Value, and then add the following registry value:
Value name: InheritConsoleHandles
Data type: REG_DWORD
Radix: Decimal
Value data: 1
Quit Registry Editor.
Warning: In principle, this should only be necessary on Windows XP. In my experience it's also necessary in Windows 7. In Windows 10 this is actively harmful—programs execute but produce nothing on stdout/stderr. The registry key needs to be set to 0 instead of 1.
See also:
STDIN/STDOUT Redirection May Not Work If Started from a File Association
Perl Scripts on Windows 10 run from Explorer but not Command Prompt
If patching the registry isn't an option running program | perl -S myscript.pl
is a less annoying work-around for scripts in your PATH.
Add a drop handler
Adding a drop handler for Perl allows you to run a Perl script via drag & drop;
e.g. dragging a file over the file icon in Windows Explorer and dropping it
there. Run the following script to add the necessary entries to the registry:
use Win32::TieRegistry;
$Registry->Delimiter("/");
$perlKey = $Registry-> {"HKEY_CLASSES_ROOT/Perl/"};
$perlKey-> {"shellex/"} = {
"DropHandler/" => {
"/" => "{86C86720-42A0-1069-A2E8-08002B30309D}"
}};
Convert your perl scripts into batch files using pl2bat once they are ready to be run by users.
The trick works through the perl -x switch which, according to perldoc perlrun, makes Perl search for the first line looking like #!.*perl.
After following the instructions in the accepted answer, a double click still led to .pl files opening with Notepad in Windows 10 — even when perl.exe was set as the default file handler.
After finding Jack Wu's comment at ActivePerl. .pl files no longer execute but open in Notepad instead I was able to run perl scripts on double-click as such:
Select and right-click a .pl file
Use the "Open With" submenu to "Choose another app"
Select "Always use this app to open .pl files" (do this now – you won't get the chance after you have selected a program)
Scroll to the bottom of the "Other options" to find "More apps", and select "Look for another app on this PC"
Navigate to C:/path/to/perl/bin/ and select Perl5.16.3.exe (or the equivalent, depending on which version of Perl you have installed: but not Perl.exe)
Then the Perl icon appears next to .pl files and a double-click leads to them opening in Perl every time, as desired.
I tried the assoc and ftype methods and they didn't work for me.
What worked was editing this registry key:
Computer\HKEY_CURRENT_USER\Software\Classes\Applications\perl.exe\shell\open\command
It was set to:
"C:\Perl64\bin\perl.exe" "%1"
When it should be:
"C:\Perl64\bin\perl.exe" "%1" %*
It is the same content as the ftype, but for arcane windows reasons, I had to set it there too.
Like some others, I had set 'assoc' and 'ftype', but also had set Notepad text editor via the GUI, and when I tried to execute a script via the command line, Windows invoked Notepad to edit the script instead of running my script.
Using the GUI to instead point the .pl file association to the script-running executable was not much of an improvement, since it would invoke the executable on my script, but would pass no command-line arguments (even when I invoked my script from the command line).
I finally found salvation here which advised me to delete some registry keys.
Key quote:
"The problem is that if you have already associated the program with the extension via the Open With dialog then you will have created an application association, instead of a file extension association, between the two. And application associations take precedence."
In my case, following the instructions to use RegEdit to delete
HKEY_CLASSES_ROOT \ Applications \ perl.exe
where perl.exe is the name of my Perl executable, and then also deleting:
HKEY_CLASSES_ROOT \ .pl
seemed to solve my problem, and then (after re-executing 'assoc' and 'ftype' commands as shown in other answers) I could then execute scripts from cmd.exe and have them run with access to their command-line parameters.
Some other related information here.
I have a perl script shared in a repository with several users across Mac and Windows machines. It performs its work on files located in the folder with it. Because I run it frequently and because some users don't even know what a command line is, I created a batch file in the directory to make it easy to launch. Because some paths will differ, I made it portable:
::figure out your directory path
pushd %~dp0
:: launch the script
perl my_perl_script.pl
popd
The batch works perfectly on Windows and I put it in each project folder with each perl script and tell my users to just "double-click that thingy."
How can I do the same on Mac? I don't know much about bash, and I can't figure out how to
1) Have a bash file figure out its directory path, and
2) Make the bash a simple "double-click that thingy" executable for my Mac users.
Would a simple Applescript be better (I don't really know Applescript either...)
Thanks for any help.
EDIT: Thanks, dj bazzie wazzie. I didn't want to run both a bash and applescript to get my perl to run, but I did use your first line to get an applescript that works perfectly for me.
set currentWorkingDirectory to do shell script "dirname " & quoted form of POSIX path of (path to me)
tell application "Terminal"
set currentTab to do script "cd " & currentWorkingDirectory
do script "perl xml2epub_3689_7KeysSpWellness.pl" in currentTab
end tell
With AppleScript you have the ability run a shell command. Let's say your bash file is located next to the script and is named maintenance.sh your script would look something like this
set currentWorkingDirectory to do shell script "dirname " & quoted form of POSIX path of (path to me)
do shell script quoted form of (currentWorkingDirectory & "/maintenance.sh")
EDIT: (I can't comment your post so I change my post)
For such a simple command as yours you don't need the terminal application. I can understand that a working application is enough but for a much smoother script I would put that command into a do shell script. So the code for your per command would be something like this
set currentWorkingDirectory to do shell script "dirname " & quoted form of POSIX path of (path to me)
do shell script "perl " & quoted form of (currentWorkingDirectory & "/xml2epub_3689_7KeysSpWellness.pl")
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
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