I have perl scripts which were running in Windows 7 just fine as of this morning. I made the mistake of using NotePad as the default for opening/editng my .pl files. Now, when I attempt to run the unedited .pl files from a DOS prompt, the script does not execute but opens the associated source code file in Windows Explorer. This is the same for all my .pl files no matter the complexity (including classic "hello world".
I have been researching changes need to the registry - it all looks fine. Tried assoc and ftype changes - nothing. Tried reinstalling ActivePerl - no solution.
You don't need to go into the Registry.
Go into Windows Explorer.
Find a file that ends in a *.pl suffix.
Right click on it and bring up the Context menu.
Select "Open With" (It might just be Open... with an ellipse after it. I don't have a Windows machine at the moment to verify this). This will bring up a dialog box with all the various programs. NOTE: Perl may not be listed in the initial set of programs. No worry, just navigate to it.
On the bottom of the dialog box is a checkbox (Something like open all extensions with this program). Make sure that checkbox is checked.
After this, all files that end with *.pl will open with Perl instead of Notepad.
It is highly likely that someone did this with a Perl script in order to edit it, and messed up the file association.
However, who ever did this should be doped slap -- not for messing up the file association, but for editing a program with Notepad. Bad Developer! No doughnuts for you!
Programs should be opened with a Program Editor. If you're a real he-man, you can use VIM. VIM is a fast, and powerful program editor, but you will need to spend an internship at the feet of a VIM Ninja master in order to learn how to use it. Your first three to six months with VIM will be What a idiotic program! This is awful. Who wrote this crap?. Then, one day, you will understand its power and efficiency. You will be one with the program.
If you aren't brave or fearless or don't have six months to waste learning a programming editor, you can use Notepad++. Compared to VIM Notepad++ is like driving a Minivan. It's safe, it's practical, and it gets the job done.
Both editors do Syntax Highlighting which can help you find issues. Both, (VIM can -- I think Notepad++ can too) offer help with syntax and usage. Both can edit a file without messing up the line endings (They'll both detect whether a file has Unix or Windows line endings and keep those or allow you to convert them). Both will number your lines, have extensive cut/paste buffers, powerful search and replace features. And will not mess up your file encoding. Both offer visual diffing between files and do automatic backups when you edit a file.
Finally, these two editors will embed themselves into the context menu you get when you right click on a file. You can edit a file by clicking on it, and selecting VIM or Notepad++ directly from the context menu. No need to select "Open with..." and possibly mess up the file suffix association.
Never ever use Notepad to edit a program.
Sounds like your .pl extention association is now set to Notepad rather than perl.exe. If you are too busy to fix that, just type "perl yourscript.pl" in a command promot window to start the perl interpreter and to send your script to it to run.
See this answer to fix the association:
File Type .pl Association and Using cmd.exe to Run the Script
I have the same problem. None of the method mentioned above solve the problem. The problem actually came from Windows 7! Windows 7 Doesn't allow you to associate .pl to perl.exe in c:\Perl64 directory, for whatever reason.
Here is the solution:
If you look at c:\Perl64\Bin directory (or the path where your ActivePerl binary installed), you'll see another file: Perl5.14.2.exe. This is the same file as perl.exe in same directory but with version number attached as postfix in the name.
You can associate .pl file to that Perl5.14.2.exe instead of perl.exe. Bingo, it works now.
Related
I need to open the file using Windows 10 cmd. But when the file opens, I need Windows to show me a modal window "How do you want to open this file?". The system should do this even if it already has a program selected by default to open a certain type of file. Is it possible to do this?
To clarify my problem:
I need the console to run for example ".py" not through the standard Python.File="C:\Windows\py.exe " "%L" %*, and for example via VS Code. You might tell me about the VS Code CLI. But how to handle an event where the user will not have VS Code, but for example Pycharm, and the user will want to open it through it? That is why the question was posed in such a way that the user could choose through what to open the file already through the built-in modal window in Windows. In any case, I will be glad of any suggestion to solve my problem.
I tried to find something similar, but apart from the standard start something.som I didn't find it. And this is not a solution to the problem, because start starts the file in the program that is specified by default in the system. This program may not even be the one that the user ever chose later. I came across a similar question in Stackoverflow, where a person wanted to see which program was responsible for opening a file with a certain extension, where assoc and ftype were used, but they did not give the desired result.
So I want to work a little bit in the interactive window in visual studio, to take a look at some F#.
Now View>other windows>F# interactive
In order to load my file I then type
>#load "Distance.fs";;
It is important to mention that Distance.fs is the current file that I am standing on.
however now, I get this error:
It looks like it keeps looking in the wrong directory, and it keeps doing this across different files and projects. Why does this happen? Is there any way I can configure VS to always open the interactive windows on the currently open directory
FSI defaults its current directory to whatever %TEMP% is and just needs a little help. Create a scratch script (as #TheQuickBrownFox suggested), and put your #load statement in there. Above that, add
open System
Environment.CurrentDirectory <- __SOURCE_DIRECTORY__
Highlight those two lines and press Alt-Enter to tell FSI to change to the script's current directory, then your #load statement should work (if needed, adjust your path, for example if you create a separate scripts folder, then maybe you now need #load "../Distance.fs", etc.
I am trying to use Jedit as an external editor to 7zip.
7zip opens Jedit as external editor however edits are only saved back if Jedit was not running previously. I probably should pass -noserver or -newview command line arguments to Jedit as an external editor, but when I do that 7zip gives an error: 'Cannot start editor'.
How could I use Jedit as an external editor to 7zip so that edits are saved back?
You cannot give arguments to the programs you configure in 7-Zip.
What you need to do is to create a batch file that you call from 7-Zip that sets the options you want to have and that forwards all other arguments.
What you do NOT want to do is to use the -noserver option without a -settings option if a jEdit instance is already running. Currently jEdit does not behave nice if you start two really separated instances in the same settings directory, as the first that writes a specific settings file after the second instance is started "owns" it and the other just does not save it anymore, so your positions, recent files, changed settings etc. will not be persisted and there is no prominent warning about this.
What you DO want to do is to use the -wait option, that is present for exactly those cases.
So create a file jedit-wait.bat (e. g. in the jEdit installation directory) with content #jedit -wait %* and then configure that batch file as 7-Zip editor. That is also how I have set it up and it works exactly like expected. The only slightly unnice thing is, that you will have a black command line window sitting there as long as you edit the file, but that is not as disturbing as it sounds, at least to me.
Warning: first-time Vim "user"
I'd like to make the GUI font much bigger.
It is installed on a modern windows 32-bit machine.
I've used the Edit menu and found a good font using Select Font...
Then I entered the command:
set gfn?
To return ...
guifont=Consolas:h16:cANSI
Now apparently I need to add something to my vimrc file. I think I have found the file here?:
So why am I now struggling to make the changes?
Whichever way I try (notepad or via Vim>Open) to open this file it seems to be read-only.
I assume once open I need to add something like the following at some point(?) in the file?
if has('gui_running')
set guifont=Consolas:h16:cANSI
endif
Because your _vimrc lives under Program Files, Windows is trying to protect you from potentially damaging the system (and is preventing potentially malicious programs from doing the same).
In order to edit your _vimrc, you need to be running Vim as administrator. Right-click the gVim icon and select Run as administrator from the menu. You should then be able to edit the file.
You'll probably want to make lots of other changes to this file over time; you'll have to remember always to edit it as administrator.
I don't know much about the windows platform, but it seems that you were editing the system vimrc. try to start (g)vim, and type :e $MYVIMRC this should be user-lvl. usually under $HOME
write the setting you want there, and save.
or you could in vim, :echo $HOME, to see which dir is your HOME. then create the _vimrc file there.
On my computer at work, any time I open a file located on a network share, GVim becomes completely unusable. Scrolling through the document can take 15 seconds to go one "page". Even using the movement keys to go from one word to another can take 2 to 3 seconds. This seems to be a new behavior, but for the life of me I can't remember changing anything that would cause it. I'm under the impression that Vim doesn't actually access a file except on open and on save. Is that right?
There are a few factors which may affect this.
First, make sure you have Vim setup to prefer storing the swapfile locally. If your $HOME is on a local drive, I tend to put this in my vimrc (which will either be at $HOME\_vimrc or $VIM\_vimrc). Make sure you create that directory, otherwise Vim will continue to use one of the other directories in the list.
set directory^=$HOME/tmp
This prepends the $HOME/tmp directory to the start of the list that Vim checks for where to place swapfiles.
Second, do the same for the backup file that Vim creates. Same situation as above but the option you'll be changing is backupdir instead of directory.
Third, make sure you disable the matchparen plugin. This plugin is new to Vim 7, so you may be used to using an older version of Vim. This causes frequent scanning of the file for matching parens, braces, etc. which can drastically slow Vim down when the file is on a network share. Again, this should go in your vimrc.
let g:loaded_matchparen = 1
If you only want to disable the plugin temporarily, you can use the command :NoMatchParen and then :DoMatchParen to re-enable it later in that Vim session.
Finally, if none of those help you can always copy the file locally and edit it.
Swap file has nothing to do with it. I have my swap file local and still have the problem. I use Process Monitor from SysInternals.com and it revealed bad behavior when attempting to open "\server\TestTool\foo\ReadMe.TXT"
It first attempts a CreateFile (aka, Directory open) on "\serve\". Notice the last character is missing. This will cause 4 seconds to time out with "OBJECT PATH INVALID".
Then it tries CreateFile on "\server\TestToo\". Server name is correct by the last letter of "TestTool" is clipped. Again, a 3 second time out with "BAD NETWORK NAME".
Finally it gets it right and calls CreateFile on "\server\TestTool\" which works right away.
Then CreateFile on "\server\TestTool\foo" which works right away.
Then CreateFile on "\server\TestTool\foo\ReadMe.TXT" which works right away.
WHY is it trying bad names for the server and the root directory??? What madness is this?
I fixed this issue after setting HOME path by force in advanced system settings.
(Your current HOME path would be a network directory.)
Control Panel > All Control Panel Items > System > Advanced system settings > Environment variables
Press "New..."
Variable name: HOME
Variable value: c:\Home\ **<-- Type your home directory**
A follow up on jamessan's answer: to disable the plugin automatically when you edit files on a share, put this line in you _vimrc
autocmd BufReadPre //* :NoMatchParen
You could consider installing LargeFile plugin. It disables a couple of features impacting the performance.
Having a similar issue as David Anderson, but no solution yet.
When loading \\ServerName\A$\B\C\File.txt Vim will do:
Open \ServerName\A$\B\C\File.txt
Then it does many loops like:
CreateFile \ServerName\A$ <-- Each taking roughly 1 sec
QueryDirectory \ServerName\A$\B
QueryDirectory \ServerName\A$
QueryDirectory \ServerName\A$\B\C
QueryDirectory \ServerName\A$\B
To compare with Notepad++ which loads files almost instantaneously there are more lines and Notepad++ never queries \\ServerName\A$.
Also the duration (Duration column) written in Process Monitor is low, but the time taken by Vim seem quiet high (Time of Day column) for the CreateFile \\ServerName\A$.
I've no plugins installed as far as I know and followed other tips to speed up network shares loading.
Note: The dollar is in the path. More weird is that Vim will load very fast on more recent Windows Server (2008 instead of 2003) with the same folder structure.
I had the same problem (slow gvim editing over network drive) and have fixed it. It was for me -- no kidding -- the titlestring.
Background: I use a vertically arranged taskbar with Windows 10. This has the advantage that my open windows behave like a growing stack from top to bottom. For example, see here some currently open windows with how-to-run.txt as a network file:
With that it makes sense, that the filename is going first in the window title of gvim and the path goes after that. So I used exactly the titlestring in my vimrc, which is still officially recommended in the help file vim81/doc/options.txt, line 8202:
set titlestring=%t%(\ %M%)%(\ (%{expand(\"%:~:.:h\")})%)%(\ %a%)
For local files that's ok, but for network files this is way too slow.
Now my fix:
set titlestring=
Same effect (filename first), but now gvim runs very fast for remote files as well!
BTW, I also tried all the above mentioned recommendations (directory, backupdir, matchparen, disabled all the plugins, tried the LargeFile plugin although I observed the slow gvim also for small files, etc.). I also changed my statusline to something really simple.
It all had no effect for me. But the funny titlestring...