No matter what my code is, even if my batch file is syntactically incorrect, even if it is absolutely correct and even if there is nothing to display on the screen the batch file when executed just displays the code as it is.
I read a similar question MSDOS prints the whole batch file on screen instead of executing but since that was on MS-DOS I hoped my issue could have a solution different than that.
Eg,
#echo off
set abcd=4
Even its batch file would just display the same lines as it is.
Please help.
Try "resetting" cmd if possible. U can try copying someone else's "cmd.exe" and replace it with yours using another bootable OS as windows wont allow that.
Here use my cmd.exe. https://drive.google.com/open?id=0B6ghonMKBfUSLVpRV0U5bG5pQTQ
Just in case u need to know I am using Windows 10 64 bit.
Check the file with an editor that allows you to see the encoding.
For example Notepad++ , you will see is very different the end of line via CF (\r) and LF (\n)
Your CMD can be recognizing EOL via \n only.
To determine whether your issue is really with line breaks being converted by your text editor (as the post you mention suggests), perform the following test:
Open a Command Line Window
Type the following command: copy con test.bat
The cursor will reposition itself under the command prompt, this is normal
Type the following 3 commands, each followed by the [Enter] key:
.
Echo Off
Set abcd=4
Echo abcd
Press CTRL-Z simultaneously (it will show up on screen as ^Z)
A confimation message should state: 1 file(s) copied.
Now type Test to run the batch file. If it runs properly, it means you are indeed dealing with line termination issues. Use a different text editor (don't use Notepad!!!), ideally one where you have an option to display the line termination characters (I personnally use NotePad++, it works great for these kinds of things but there are many others out there).
Perhaps there is a problem with your environment variables. Check the following:
Press WIN + R and run "%SYSTEMROOT%\System32\SystemPropertiesAdvanced.exe"
Click on "Environment Variables"
The system variables are listed at the bottom. Select the variable "Path" and click "Edit..."
Check whether the list contains "C:\Windows\System32" or "%SYSTEMROOT%\System32". If not, add one of those. You may have to restart your computer afterwards.
Related
This might seem a bit too obvious but I am stuck with it anyway.
I am editing an ffmpeg code in notepad++ and I want to run the selected line of code directly in notepad++ console (nppexec plugin console).
say, I have four lines of code, and I want to run only the second line (selected line):
currently, I am coping the line and pasting it in the console and hitting enter. I know it is very noobie!
Please help to achieve this with a shortcut or something.
Once I created a small nppexex script, to run an external command on the selection, based on that you can use a nppexec script like:
sel_saveto c:\Temp\NPP_Selection.bat
cmd /c c:\Temp\NPP_Selection.bat
Please save your file with the ffmpeg command with ansi encoding (with UTF8 there was an error with some strange characters at the start of the selection).
The script stores the selection in a bat file and then runs it with cmd /c
I am aware that it is possible to permanently alter the 'prompt' variable (the command prompt that begins every command line, defaulting to the current drive and path, followed by a greater than sign (>)) in the Command Prompt by adding an Environment Variable named 'Prompt' and setting the value to that which can be set by running the prompt command.
However, I am curious to know if it is possible to set the Window Title of the command prompt (this is possible by running title [insert value here]), perhaps by setting a parameter in the cmd.exe file settings. Unfortunately I do not know if this is possible, and if so the correct syntax to get it to work. Hence my question here. I have looked in many places for an answer to this question, but I seemingly find only sites with details on command parameters being executed within the prompt itself.
There is now a way to set the title text in Windows 10 using the PROMPT variable itself, since the Windows 10 console host now recognizes ANSI control codes, but it can be a bit tricky. This is the value of my PROMPT variable:
$E]0; $p ^G$E[1;37;44m$t$s$p$g$e[0m
This gives me a prompt with the time, the current directory and a > with bold white foreground on a blue background. It also sets the window title to the current working directory.
$p and $g you presumably already know. $t inserts the time. $s inserts a space. $e inserts an ESC character. (PROMPT documentation)
$e]0; begins the ANSI sequence to set the window title. It is ended with a ^G (\007) the BEL character. This is where the tricky part lies. Setting this on the command line is trivial; you can simply type Alt+007 or hit ^G on your keyboard. Setting it in the environment variables in the registry is the hard part. The Windows edit box for environment variables ignores the control codes. I resorted to a .reg file to get it set.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
"PROMPT"="$E]0; $p $E[1;37;44m$t$s$p$g$e[0m"
The ^G character shows as a square box for me here. You need to get that ^G character into that spot in the prompt string.
See the Wikipedia article on ANSI codes for more on what you can do with it.
Simpler way: Start ---> cmd ---> Right-Click ---> Open File Location ---> Right-Click "Command Prompt.exe" ---> Rename ---> ---> Enter ---> Steps 1-2 ---> Click/Right-Click+Run as administrator.
What to change through Properties
Permanent change to cmd title when you open it through Start ---> cmd ---> Left-Click/Right-Click+Run as administrator:
One can create a String key in Computer\HKEY_CURRENT_USER\Software\Microsoft\Command Processor or HKEY_CURRENT_USER\Software\Microsoft\Command Processor named AutoRun, with a value for the Window Title. This will a set the title bar of Command Prompt to the value specified in the key.
Make a registry file:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"CompletionChar"=dword:00000009
"DefaultColor"=dword:00000000
"EnableExtensions"=dword:00000001
"AutoRun"="title Hello &cls"
change autorun's value to any command, that always run at the begining. just likeÆdx said ;)
Easiest Way:
Right click on desktop and go to "new"
Click "shortcut" and type in "cmd.exe" for file location
Title it whatever you want!
(It will always have the title you selected unless you open it through the "run" box.)
Go to this link below for more help:
https://www.youtube.com/watch?v=dQw4w9WgXcQ
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...
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
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.