How can I use gvim for svn commit messages under Windows? - windows

Under *nix I can set SVN_EDITOR to gvim --nofork to do the trick, but that doesn't seem to work under Windows. Is there any solution for that?

If you have installed the batch files (c:\windows\gvim.bat), just set EDITOR to gvim -f, the batch file processes the -f argument and sets the no-fork option.
The trick in the batch file is running START /WAIT path\to\gvim.exe %* (see the /WAIT argument).
If you don't have the batch files, just create a new one with the command above, and set EDITOR to the newly create batch file.

This answer was written for Git, but should directly apply.
To make this work, try the following.
Create a one-line batch file (named svn_editor.bat) which contains the following:
"path/to/gvim.exe" --nofork "%*"
Place svn_editor.bat on your PATH.
Set SVN_EDITOR=svn_editor.bat
With this done, SVN should correctly invoke the gvim executable.
NOTE 1: The --nofork option to gvim insures that it blocks until the commit message has been written.
NOTE 2: The quotes around the path to gvim is required if you have spaces in the path.
NOTE 3: The quotes around "%*" are needed just in case git passes a file path with spaces.

If the problem is passing parameters to prevent forking to gvim (your question was a little vague), then you can either create a batch file that calls gvim with the required parameters or you could simply add the following to your vimrc (NOT gvimrc) and point SVN_EDITOR at gvim.exe:
set guioptions+=f
This tells vim not to fork when creating the GUI and has the advantage of not having to mess around with batch files. For more information, see:
:help gui-fork

Related

Windows command prompt custom commands

I am looking for a way to customise some of the Windows command prompt (cmd.exe) commands. I would like the new command to be called instead of the one defined by Windows to do almost the same thing except some minor customisations. An example could be with the pushd command print a message saying which directory is changing to. This could be useful, for example, to have the output a .bat script parsed by another tool.
As an example, pushd.bat would look like:
#echo off
pushd %1
echo Entering directory `%cd%'
...but where should I put this so that it gets called instead of the internal command pushd?
You should not customize internal commands because some of these commands go all the way back to DOS and have hidden bugs and features that some tools might rely on and it is unlikely that you will implement them correctly.
You can add custom aliases with doskey. These are better than batch files. They allow you to add certain mini scripts that help you in your daily command line usage. These can actually override the names of internal commands.
doskey pushd=echo Entering $*^&pushd $*
pushd c:\Windows
You can add your doskey commands to HKCU\Software\Microsoft\Command Processor\AutoRun in the registry but you really need to be careful if you use it to change existing commands. I recommend that you invent new names for your commands.

Change all file endings via batch

I need to change all file endings in one folder from .sic to .edi via a windows batch file. As I usually don't work with cmd or else (mostly doing html work...), I don't really know how to start this. I couldn't find an existing question matching my requirements either.
The following single line should do it!
Ren "YourFolderPath\*.sic" *.edi
Very simple:
ren *.sic *.edi
Just create a batch file with that line, or just go into Command Prompt and type it in manually.
This is one use case where Windows batch is easier than Linux shells.

"edit" not a valid command in cmd.exe?

I'm trying to create a .cfg file for bcc32 compiler and I'm following the instructions. I have installed correctly and placed an environment path as instructed but when I type "edit bcc32.cfg" into the command prompt it says that edit isn't a valid command? What am I supposed to do?
You could also create a .bat file, edit.bat, to replace the 16-bit edit program (removed because x64 windows flavors won't run it) which would launch your favorite editor.
#echo off
notepad %1
#echo on
This is what I wound up doing as a simple patch so I could carry on the way I always had for the most part. Just type:
edit myfile.ext
in the command prompt to use it.
Note: notepad is not my favorite editor - this is just an example that will work with stock windows.
Note 2: #echo off and #echo on are shown for clarity. You may also shorten this by omitting the echo statements and simply placing the # before the command to be silenced.
#notepad %1
I just use notepad (since they took out the edit command) from the command window like so:
C:\Borland\BCC55\bin> notepad bcc32.cfg
The file will open in notepad for editing. When you've finished editing the file, save it and you're done.
I have found this works for seeing in-window text of a complete file, on a 64bit machine. Once your path is set in cmd prompt, type the word type... followed by "filename" do you see how I used the quotes around the filename only!
type "filename"
You type it just like this (changing filename for your files name) and you will be able to see the entire file text in the cmd window. Not sure how to edit from here on but maybe someone can figure it out from here and tell me.
Assuming you're using Windows 7 (where edit.exe and edlin.exe have been removed):
Use powershell.exe instead of cmd - thereby edit will be available via command line.
Take a look at: http://en.wikipedia.org/wiki/Windows_PowerShell
simple answer....
if your using an old version of windows (xp e.t.c...) you would be able to use edit
but since your using new version of windows, Microsoft has updated and removed the commands that they think are not relevant e.g.. (msg, edit) depending if its a bit32 bit64 or bit82...

Filtering lines through external program on Windows returns nothing

Inside Vim on Windows, I'm trying to filter the lines in a file through a shell executable. I'm using the following command:
:0,$!sort
The idea being that I'll sort the lines of the file using the Windows sort command.
The issue is that I get nothing back so, effectively, all the lines in the file are deleted, i.e. they are replaced with nothing (I can recover all the lines using undo u).
Outside of Vim, the following command works fine:
type sort-lines.txt | sort
("sort-lines.txt" is the test file that I'm working with in vim.)
I've tried this with the Windows sort command as well as with the Cygwin sort command. The results are the same.
Interestingly, if I use the following command in Vim:
:0,$!dir
The lines of the file are replaced with the output from the dir command. This makes me think that the external program is executing, but it isn't correctly receiving the input lines from the file.
Is there something that needs to be adjusted in my configuration to make this work? I checked the value of Vim's shellpipe option and it is set to:
shellpipe=>%s 2>&1
which doesn't seem right to me.
Okay, I found the issue.
I had an Autorun CMD script set in my registry. Whenever vim would spin up CMD to run the filter, the Autorun script would run and somehow block the piped-in data from getting in.
To workaround the issue, I changed the value of the vim "shell" variable. Here is what I set it to.
:set shell=C:\Windows\system32\cmd.exe\ /d
The /d tells CMD not to run any Autorun scripts. The extra backslash after the "cmd.exe" is necessary in order to escape the space character between cmd.exe and the /d.
With this setting in place, filtering works correctly.
For a discussion of Autorun and the /d option see this MSDN article
Thanks, Darcy, for pointing me in the right direction. (BTW, you have a great last name.)
vim has a built-in sort utility. You can try that.
:0,$sort

How do I create drag-and-drop Strawberry Perl programs?

I've got a Strawberry Perl program that accepts a single-file as a command-line argument. How can I set things up such that I can drag and drop the desired file onto the Strawberry Perl program (or a wrapper around it) and the program runs with that file's name as an argument?
Under Windows (tested with XP), you can create a .cmd file and simply have it run the Perl program with the argument of %1 to pass the filename over, as if executed by commandline.
perl c:\test.pl %1
Then you can simply drag and drop a file onto the .cmd file to execute.
Eeek! Please don't create a wrapper script/cmd when you don't need to.
Go into your Registry or your File Type dialog box in Windows, and redefine the Perl default action to say:
"C:\path-to-perl-folders\perl.exe" "%1" %*
This will cause double-clicking the .PL to launch perl.exe with the name of the double-clicked file (%1). The %* stuff (passing any filename arguments to the Perl script) is trickier.
Go into the Registry again (really, it's not as scary as people think) and find/create a "shellex" key under the Perl class, and then create a sub-key called "DropHandler" with a default string value of "{86C86720-42A0-1069-A2E8-08002B30309D}" (at least, that's my DropHandler in the US version of Windows XP).
This allows .pl files (actually, anything associated with the Perl class) to have a drop handler that tells Explorer what to do when you drop file(s) on the .pl script. In this case, it just means "run the Perl script with the dropped file(s) as arguments".
Hmmm, I don't think I explained that very well, but that's how I've set up Perl (running off a network drive) for a large engineering organization. Google for Perl and DropHandler, and you should be able to get the .reg Registry script to do this for you.
Here's another alternative to a "wrapper", but it requires a slight modification to the perl script:
Rename your script.pl script to script.cmd.
Add the following to the top of the file:
#SETLOCAL ENABLEEXTENSIONS
#c:\path\to\perl.exe -x "%~f0" %*
#exit /b %ERRORLEVEL%
#!perl
#line 6
# ...perl script continues here...
The script is run like any other batch file. The first three lines basically invokes Perl on the CMD file itself (%~f0, which only works if CMD extensions are turned on). The -x paremeter to perl.exe tells Perl to skip everything until the #!perl line. "#line 6" just aids in debugging.
This is my preferred solution when I don't know much about the target system (and may not be able to edit the registry).

Resources