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.
I usually perform actions in the 7zip command line program. I was thinking about creating a small script to do everything automatically, but I have never written any Windows shell script before and therefore don't even know where to begin.
I would like to make an executable script file which, when a user double-clicks on it, will call the 7zip command line and perform some actions.
First of all, is this possible? And if it is, what is the best way to do this?
You can create a batch script to do this.
It's basically command line commands that run one after another so you don't have to keep typing them in :)
Put the commands you would normally use for 7zip in a notepad file and save it with the extension .bat, then run it.
7z blah blah params
7z more params and args
All your commands will be executed automatically when the previous one finishes.
There are other programming languages you could do this in (or even VBScript) but batch would be perfectly suited to this, and you don't need to install anything extra.
Batch files can run a series of command line commands. Simply create a text file and name it with the .bat extension.
There are plenty of resources on the internet which will provide you with help.
I am a Windows 7 User who wants to convert multiple *.eps files to pdf-files. Therefore I installed a program called EPSPDF.rb.
I integrated it into my systempath which makes me use it in the command prompt like this:
C:\TEMP>epspdf somefile.eps
The program converts somefile.eps to somefile.pdf.
What I am trying to achieve now is writing a Windows Batch File which will look in
the directory C:\TEMP for all *.eps files and convert them all.
I am still trying hard since I am quite unfamiliar with the programming language.
I guess writing the few lines will be an easy issue for someone who is familiar with Batch Files in Windows. I will be very grateful for any help!
for %%f in (*.eps) do epspfd %%f
This is for use in a batch file. You can run it right on the command prompt, only you need to use %f instead of %%f. Just because. ;)
for %F in (*.eps) do epspdf %F
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
While running a batch file in Windows XP I have found randomly occurring error message:
The system cannot find the batch label specified name_of_label
Of course label existed. What causes this error?
Actually, you need 2 conditions for this to happen:
the batch file must not use CRLF line endings
the label you jump to must span a block boundary (as opposed to and :end label wich is just a shortcut to the end of your script)
See. The system cannot find the batch label specified (by and Batch-as-batch-can!
David A. Gray mentions in the comments seeing (on Windows 10) what Marshal's answer showed in 2014 (presumably on Windows 7 or 8): a script/batch program (.bat or .cmd) executed without CALL would trigger an eol conversion.
I've written hundreds of batch scripts over the last 35 years, and the only time I've ever had an issue with labels not being found was when the file's line breaks got converted from Windows (CR/LF), which works, to Unix (LF), which doesn't.
Feb. 2020, kinar adds in the comments:
Just encountered this issue on a Win7 machine.
Turns out this error can also be generated when trying to CALL another .bat file if that file doesn't exist on the system.
In my case, I was trying to call the Visual Studio vcvarsall.bat file on a system without VS installed.
See jeb's answer for more: it was a case of an undefined label.
Note: in a Git repository, I would recommend a .gitattributes file with the directive:
*.bat text eol=crlf
I have got the same issue before. However, the root cause was not CRLF at all. It was because in the script I executed an external program such as Ant, but did not put a CALL before Ant. So, make sure you CALL every external program used in your batch script.
If batch file has unix line endings (line separators) this can sometimes happen.
Just unix2dos it and problem should be solved.
Here is the issue and how to fix it. The issue is a bug or a feature in DOS batch cmd program. First the clear problem statement. If you have a DOS batch file with target labels like, ":dothis", and at the end of the label you do not have space then the batch file will not work if the line ending are UNIX line endings. This means you have to run unix2dos on the file before you can use it.
The root cause is the DOS command line processor, (shell program), takes the UNIX end-of-line character as part of the label. Since the go to part never uses this as the label, it is never found since such a label truly does not exist. The solution is to put an extra space at the end of each target label, or even better every line. Now UNIX end of lines do not come to play since the space acts as the separator and it all works.
You should also make sure that when calling other scripts you use CALL, instead of calling them in the caller's environment.
I encountered a similar issue just now with a .cmd file and Windows 8.
The solution was to change all line endings to CR+LF DOS style.
The issue was confusing because the batch file mostly worked and rearranging lines changed the effect.
The .cmd file looked like:
call:function_A "..\..\folderA\"
call:function_B "..\..\folderB\"
call:function_C "..\..\folderC\"
call:function_D "..\..\folderD\"
goto:eof
:function_A
rem do stuff
goto:eof
...etc...
Function C would cause error "The system cannot find the batch label specified". Strangely it could go away by rearranging the calls.
Changing line endings from 0x0A to 0x0D0A seems to have fixed it.
Perhaps VonC meant "the batch file must use CRLF line endings".
There are multiple possible ways to get the error.
Described by VonC - Wrong line endings, LF instead of CR/LF
Obscure long lines (if that happens accidential, your code is incredible worse)
Direct start another batch after calling a function.
Sample:#echo off
call :func
echo back from second
exit /b
:func
second.bat
echo NEVER COME BACK HERE
This unexpectedly tries to goto to the label :func in second.bat.
But this can be (mis)-used to directly call labels in another batch file
This is the described behaviour of the answer of Marshal
i had this issue after copying a start command from word and paste it into the command window. There was a option with "-" on front, and thought the looks the same as the DOS "-" it wasn't :) After typing the "-" by myself the issue was solved and the batch worked ... a hard to find issue ....
Little different use case ...
I was calling a bat script during packer build of Windows Server 2012 Server, using the shell provisioner (OpenSSH).
Now, the script was working fine through cmd in the provisioned Virtual Machine (put breakpoint in packer build to stop and confirmed this) ... but, it was failing with these call labels not found issues.
The Line Endings were fine, CRLF (confirmed in Notepadd++). The script was working fine through command line as well. What more, sometimes, it just use to run fine and sometime fail, but once failed for some label, the failure was consistent.
Initially, I just started removing the subroutines altogether by expanding the call itself and putting subroutine code inline. I did this for all instances where there was only one call (no code duplication).
But, yeah, i did stumble upon one sub which was called from 3,4 places. After trying everything, this is what worked for me
Adding 8-10 REM statements just above the subroutine. Yes, I am not kidding !!
PS : The script is very very old, but management needed me to make that work through packer (we have a Day-2 plan of this to replace it with Ansible/Chef).
I had the error :
The system cannot find the batch label specified -
and I found that on a line I used
goto : eof
instead
goto :eof
So check for the same issue of using labels, if the solutions from above didn't worked out.