The following illustrates a problem I found using for /f %l in ('<command>') do #(echo %l). (/f is the for command's parameter for "iterating and file parsing.") This works as expected when <command> is cd or chdir, but not when <command> is pushd:
C:\>cd
C:\
C:\>for /f %l in ('cd') do #(echo %l)
C:\
C:\>chdir
C:\
C:\>for /f %l in ('chdir') do #(echo %l)
C:\
C:\>pushd Windows
C:\Windows>pushd
C:\
C:\Windows>for /f %l in ('pushd') do #(echo %l)
C:\Windows>pushd > nul
C:\Windows>
I would expect the last command to print C:\ but it does not execute the do block at all. I added pushd > nul to check that pushd prints to stdout.
How can I process the output of pushd in a for /f loop?
Information about command processing by FOR /F
The usage of a for /F loop with a command enclosed in ' or in ` on using usebackq results in starting in background one more command process using %ComSpec% /c and the command appended as additional argument(s).
The usage of for /f %l in ('pushd') do #(echo %l) results in background execution of:
C:\Windows\System32\cmd.exe /c pushd
That can be seen by downloading, extracting and running the free Windows Sysinternals tool Process Monitor as administrator which logs the execution of two cmd.exe processes with different process identifiers on running the commands as posted in the question. There must be double clicked on any line in log of Process Monitor of second cmd.exe in the middle of the log to open the Event Properties window and selected the second tab Process to see the Command Line which was used by first cmd.exe to start the second cmd.exe for the execution of the command pushd.
There cannot be executed just a single command with a for /F loop. There can be executed an entire command line which can even have multiple commands. But it is necessary to take into account all the information given by the usage help of cmd output on running cmd /? in a command prompt window on using a complex command line with for /F and processing its output as written to handle STDOUT of in background started cmd.exe.
Command operators like &, && and || as well as redirection operators like |, 2> and 2>&1 in the command line to execute by for /F are processed by two cmd.exe, first the one executing the entire for /F loop and another one started in background with the command line of which output is of interest. That is the reason why many for /F loops with a complex command line are with the escape character ^ left to each & and | and > in the command line to get these characters interpreted literally by cmd.exe parsing and executing the entire for /F loop while being interpreted as command/redirection operators by the second cmd.exe started in background which is really executing the command line.
Information about output of PUSHD
The Windows command PUSHD outputs on execution without any directory path the list of directory paths pushed on stack of current command process.
There can be executed in a command prompt window following commands:
cd /D %SystemDrive%\
pushd %SystemRoot%
pushd inf
pushd
popd
popd
The fifth command pushd results usually for typical Windows installations in the output:
C:\Windows
C:\
But there is nothing output by using as fifth command instead of pushd the command line:
for /F "delims=" %I in ('pushd') do #echo %I
The reason is the execution of pushd by one more cmd.exe started in background which has no directory paths pushed on its stack. The internal command PUSHD does not output anything at all for that reason to handle STDOUT of in background started cmd.exe.
The command process running for /F cannot capture any output text. The for /F loop cannot process therefore any line after cmd.exe started in background finished the execution of pushd and closed itself.
How to process the directory paths pushed on stack?
It would be necessary to use the following command lines in the command prompt window to process the directory paths pushed on stack of the current command process:
pushd >"%TEMP%\DirectoryList.tmp"
if exist "%TEMP%\DirectoryList.tmp" for /F "usebackq delims=" %I in ("%TEMP%\DirectoryList.txt") do #echo %I
del "%TEMP%\DirectoryList.tmp" 2>nul
The redirection of the output of PUSHD executed by the command process which executed also the two pushd command lines before into a temporary file makes it possible to process the directory paths pushed on stack of current command process.
The for /F option usebackq is necessary to get the string inside " interpreted as file name of which lines to process by the FOR loop and not as string to process.
The for /F option delims= is necessary to define an empty list of string delimiters as a directory path can contain one or more spaces. There is by default split up a line into substrings using normal space and horizontal tab as string delimiters and assigned to the loop variable is just the first space/tab delimited string instead of the entire directory path. The line splitting is turned off by the definition of an empty list of delimiters. The entire directory path is assigned therefore always to the loop variable in this case with processing always full directory paths never starting with the default end of line character ; as the first character is always either a drive letter or a backslash in case of a UNC directory path.
Why does the command CD work with a FOR /F loop?
The command CD works also with for /F "delims=" %I in ('cd') do #echo %I because of cmd.exe calls the Windows kernel library function CreateProcess on starting the additional command process for execution of a command specified as set of a for /F loop with value NULL for the function parameter lpCurrentDirectory. The current directory of in background started cmd.exe is set by CreateProcess for that reason with the current directory of the command process executing the for /F command line. Both running command processes have the same current directory during the execution of the command of a for /F loop.
Information about environment variable ComSpec
ComSpec is an environment variable defined by default with %SystemRoot%\system32\cmd.exe (with s at beginning of System32 instead of S as the folder name is in real by default) as system environment variable stored in Windows registry under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.
It is really not advisable to ever modify or even delete the environment variable ComSpec neither in local environment of a running process nor in the Windows registry. That would cause a lot of programs to stop working normally as lots of executables depend internally on the correct definition of this environment variable including cmd.exe itself.
The reason is that many applications and scripts use internally the function system which uses the environment variable ComSpec to start on Windows cmd.exe for execution of a command line.
There are many batch files running internal command ver of cmd.exe to get the Windows version like:
for /F "tokens=2 delims=[]" %%G in ('ver') do for /F "tokens=2" %%H in ("%%G") do echo %%H
That works only for Windows NT based Windows versions using cmd.exe as command processor and not for older Windows versions using COMMAND.COM like Windows 95/98/ME for processing a batch file. It works only with enabled command extensions which are enabled by Windows default, but can be disabled by command setlocal DisableExtension in a batch file, on starting cmd.exe with /E:OFF or by a registry value which should be really never used and therefore not written here. The command ver must be really executed by %SystemRoot%\System32\cmd.exe because of in real is output the version of cmd.exe and not the version of Windows.
However, that command line is very good to demonstrate what happens on usage of for /F if the environment variable ComSpec is not defined in environment of cmd.exe on running the batch file with the two for /F loops.
ComSpec usage by cmd.exe on Windows XP
On Windows XP is always called C:\WINDOWS\system32\cmd.exe /c ver even on doing following:
Copying cmd.exe to the directory F:\Temp\system32.
Starting F:\Temp\system32\cmd.exe with a double click in Windows Explorer.
Running set ComSpec=F:\Temp\system32\cmd.exe and set SystemRoot=F:\Temp and set SystemDrive=F: and set windir=F:\Temp.
Verifying with echo %__APPDIR__% that F:\Temp\system32\ is output.
Running the batch file with the command line as posted above.
That can be seen with Process Monitor v3.61 on Windows XP x86.
There can be even modified the local environment variable PATH to begin with F:\Temp\system32 instead of C:\WINDOWS\system32 or the local environment variable ComSpec is deleted with set ComSpec=. The Windows Command Processor of Windows XP in directory F:\Temp\system32 calls nevertheless always C:\WINDOWS\system32\cmd.exe with the option /c and the command ver on running the batch file immediately after closing the batch file containing just the single command line in the text editor.
There cannot be seen in Process Monitor even a Windows registry access by cmd.exe of Windows XP to get any directory path.
Please read further why cmd.exe of Windows XP in a different directory than %SystemRoot%\System32\cmd.exe calls nevertheless the command processor executable in Windows system directory even after modification of local environment variable ComSpec or its deletion.
ComSpec usage of cmd.exe on Windows Vista/7/8/8.1/10/11
The same procedure as described above for Windows XP can be executed also on Windows 7 x64 and newer 64-bit Windows versions.
The double clicked 64-bit F:\Temp\system32\cmd.exe copied from C:\Windows\System32 outputs on Windows 7 and currently latest Windows 11 22H2 first:
The system cannot find message text for message number 0x2350 in the message file for Application.
(c) Microsoft Corporation. All rights reserved.
Note: The copyright message line depends on version of cmd.exe. The output above is from cmd.exe of version 10.0.22621.963 (Windows 11 22H2).
The Windows Command Processor cmd.exe of version 6.1.7601 of Windows 7 outputs additionally the line:
Not enough storage is available to process this command.
The execution of the internal command ver executed in the command prompt window opened with a double click on F:\Temp\System32\cmd.exe fails on Windows 7 and all later Windows versions up to currently latest Windows 11 22H2 which is the reason for the strange output on starting F:\Temp\System32\cmd.exe with a double click.
There can be redefined also the environment variables as described above and done on German Windows XP by me on my tests. A verification of the output of echo %__APPDIR__% works and shows F:\Temp\system32\ as expected. So, it works to access the string value of the internal dynamic variable of cmd.exe even on executed cmd.exe is not in the directory %SystemRoot%\System32.
But the batch file execution from within the command prompt of F:\Temp\system32\cmd.exe as on Windows XP results in no output at all.
In log of Process Monitor v3.70 or a newer Process Monitor version can be seen that on Windows 7 and Windows 11 22H2 is executed F:\Temp\System32\cmd.exe /c ver. That means it is indeed possible that another cmd.exe is executed instead of C:\Windows\System32\cmd.exe on Windows 7 and newer Windows versions.
But why is no version output?
Well, the execution of ver results in the output of the error message:
The system cannot find message text for message number 0x2350 in the message file for Application.
64-bit cmd.exe is not working in F:\Temp\system32 at all.
The usage of 32-bit cmd.exe copied from C:\Windows\SysWOW64 to F:\Temp\system32 makes no difference. The same error messages are output already on starting F:\Temp\system32\cmd.exe and on running next ver or the batch file after modification of local environment variable ComSpec.
Conclusion: cmd.exe of Windows Vista and newer versions are not fully working on being stored outside the appropriate system directory %SystemRoot%\System32 or %SystemRoot%\SysWOW64 while cmd.exe of Windows XP works fine in any directory.
Caching of ComSpec value
I found out with lots of further tests that the string value of the environment variable ComSpec is indeed used to find cmd.exe to run command ver on execution of the batch file with the for /F loop. But there is a caching mechanism on Windows Vista and newer Windows versions.
There must be run immediately set ComSpec=F:\Temp\system32\cmd.exe after starting F:\Temp\system32\cmd.exe before running the batch file. This results in calling F:\Temp\system32\cmd.exe /c ver. If there is next executed set ComSpec=C:\Windows\System32\cmd.exe to redefine the variable with correct value and run the batch file once again, there is nevertheless run now not working F:\Temp\system32\cmd.exe /c ver.
The same caching mechanism can be seen on starting F:\Temp\system32\cmd.exe, then running the batch file resulting in calling in background C:\Windows\System32\cmd.exe /c ver, next running set ComSpec=F:\Temp\system32\cmd.exe and running now the batch file again. There is executed once again C:\Windows\System32\cmd.exe /c ver although the value of the environment variable ComSpec is now F:\Temp\system32\cmd.exe.
It looks like cmd.exe of Windows Vista/7/8/8.1/10/11 reads the value of ComSpec only once and keeps its value in memory for further usage without reading the environment variable a second time on string value for the default command interpreter being already in its internal memory.
That is quite clever in my opinion. The string value of ComSpec is read only once from the environment variable on first usage and then is used that string internally on further usage because of the value of the environment variable ComSpec changes usually never as long as cmd.exe is running.
It looks like cmd.exe of Windows XP has nearly the same caching mechanism for the string value of the environment variable ComSpec. The difference is that cmd.exe of Windows XP reads the value of ComSpec already on starting it and not on first usage and so all changes done on local environment variable ComSpec of an already running cmd.exe have no effect on the execution of one more cmd.exe on processing a for /F loop with a command line to execute, capturing the output and processing it as I could find out with further tests on German Windows XP.
Platform: Windows Vista Service Pack 2 (x86)
I was messing around with batch scripts and realized that they could act as the command prompt(yes I know batch scripts run threw the command prompt) I mean that a batch script could prompt the user for a command and then call the command.
SET command=
SET /P command=%cd%^>
ECHO(
%command%
ECHO(
The only problem is that when I type in for example cd %windir% I get an error message telling me that the system cannot find the path specified. So I typed echo %windir% and echo printed %windir% exactly it wasn't expanded at all. I am wondering if the problem is because I have the environment variable nested inside the %command% variable but from what I understand CMD.exe does support nested environment variables. I tried using Delayed Expansion but the variable still didn't expand.
Add a call or cmd /c to evaluate variables that way.
#echo off
setlocal
SET /P command=%cd%^>
call %command%
ECHO;
I know that in the unix world, if you edit your .profile or .cshrc file, you can do a source ~/.profile or source ~/.cshrc to get the effect on your current session. If I changed something in the system variable on Windows, how can I have it effect the current command prompt session without exiting the command prompt session and opening another command prompt session?
In the usual Windows command prompt (i.e. cmd.exe), just using call mybat.bat did what I wanted. I got all the environment variables it had set.
The dos shell will support .bat files containing just assignments to variables that, when executed, will create the variables in the current environment.
c:> type EnvSetTest.bat
set TESTXYZ=XYZ
c:> .\EnvSetTest.bat
c:> set | find "TESTX"
TESTXYZ=XYZ
c:>
IHTH.
Following example will help you to solve your problem.
env.bat This file is for setting variables. Its contents are given blow.
set name="test3"
test.bat Our main batch file.
call env.bat
call print.bat
pause
Now print.bat batch file to print variables. Its contents given below
echo %name%
I am afraid not, but you can start using Powershell, which does support dot sourcing. Since powershell window is really based on cmd so all your dos command will continue to work, and you gain new power, much more power.
The only way I have found this to work is to launch a new cmd window from my own config window. eg:
#echo off
echo Loading...
setlocal enabledelayedexpansion
call 1.cmd
call 2.bat
...
...
if "%LocalAppData%"=="" set LocalAppData=%UserProfile%\Local Settings\Application Data
SET BLAHNAME=FILE:%LocalAppData%\BLAH
call blah blah
cmd
The last cmd will launch a new cmd prompt with the desired settings exported to the command window.
Here's a workaround for some limited use-cases. You can read-in a file of commands and execute them in-line. For example the calling command file looks like:
echo OFF
SETLOCAL ENABLEDELAYEDEXPANSION
:
echo. ----------------
echo. set-up java
echo. ----------------
echo.
rem call %DEV_SCRIPTS%\setup-java
for /F "tokens=*" %%A in ( %DEV_SCRIPTS%\setup-java.bat ) do (
%%A
)
call %DEV_SCRIPTS%\show-java
:
In the setup-java.bat file you can't use % expansion. You need to use !; e.g.:
set JRE_HOME=!JRE_08!
rem
set JRE_TARGET=!JRE_HOME!
So you are litterally source-ing commands from a text file. You will need to test which commands sourced in this way. It took a few trials just to set some environment variables.
I don't think we can do logic or loops because the command processor scans the file at the start. I am OK just having a simple workaround to reuse shared things like environment definitions. Most other things won't need an actual source command (I am hoping). Good luck.
For example to set VC# vars
C:\Windows\System32\cmd.exe /k "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
Use git bash for windows, it works totally fine!
this question might seem counter-useful.
the path for the windows command line prompt is different across several windows OSes. i'd like to know if there is a command i can enter in the command line prompt that will output the path of the command line prompt.
The COMSPEC environment variable contains this information. It seems to be available consistently since the olden days of MS-DOS. (Wikipedia article)
echo %COMSPEC%
C:\Windows\System32\cmd.exe
Note that it can be altered freely using SET COMSPEC=, so it's not 1000% reliable.
I use a script called which.bat which prints out the full path to a specified executable (equivalent to Unix which or whereis):
#for %%e in (%PATHEXT%) do #for %%i in (%1%%e) do #if NOT "%%~$PATH:i"=="" echo %%~$PATH:i
So, to find out the path to the cmd program you would invoke the following:
> which.bat cmd
C:\WINDOWS\system32\cmd.exe
I have a Windows .bat file which I would like to accept user input and then use the results of that input as part of the call to additional commands.
For example, I'd like to accept a process ID from the user, and then run jstack against that ID, putting the results of the jstack call into a file. However, when I try this, it doesn't work.
Here's my sample bat file contents:
#echo off
set /p id=Enter ID:
echo %id%
jstack > jstack.txt
and here's what shows up in jstack.txt:
Enter ID: Terminate batch job (Y/N)?
Try this:
#echo off
set /p "id=Enter ID: "
You can then use %id% as a parameter to another batch file like jstack %id%.
For example:
set /P id=Enter id:
jstack %id% > jstack.txt
The syntax is as such: set /p variable=[string]
Check out http://commandwindows.com/batch.htm or http://www.robvanderwoude.com/userinput.php for a more deep dive into user input with the different versions of Windows OS batch files.
Once you have set your variable, you can then go about using it in the following fashion.
#echo off
set /p UserInputPath=What Directory would you like?
cd C:\%UserInputPath%
note the %VariableName% syntax
set /p choice= "Please Select one of the above options :"
echo '%choice%'
The space after = is very important.
I am not sure if this is the case for all versions of Windows, however on the XP machine I have, I need to use the following:
set /p Var1="Prompt String"
Without the prompt string in quotes, I get various results depending on the text.
#echo off
set /p input="Write something, it will be used in the command "echo""
echo %input%
pause
if i get what you want, this works fine. you can use %input% in other commands too.
#echo off
echo Write something, it will be used in the command "echo"
set /p input=""
cls
echo %input%
pause
There is no documented /prompt parameter for SETX as there is for SET.
If you need to prompt for an environment variable that will survive reboots, you can use SETX to store it.
A variable created by SETX won't be usable until you restart the command prompt. Neatly, however, you can SETX a variable that has already been SET, even if it has the same name.
This works for me in Windows 8.1 Pro:
set /p UserInfo= "What is your name? "
setx UserInfo "%UserInfo%"
(The quotation marks around the existing variable are necessary.)
This procedure allows you to use the temporary SET-created variable during the current session and will allow you to reuse the SETX-created variable upon reboot of the computer or restart of the CMD prompt.
(Edited to format code paragraphs properly.)
#echo off
:start
set /p var1="Enter first number: "
pause
You can try also with userInput.bat which uses the html input element.
This will assign the input to the value jstackId:
call userInput.bat jstackId
echo %jstackId%
This will just print the input value which eventually you can capture with FOR /F :
call userInput.bat
There are two possibilities.
You forgot to put the %id% in the jstack call.
jstack %id% > jstack.txt
So the whole correct batch file should be:
#echo off
set /p id=Enter ID:
echo %id%
jstack %id% > jstack.txt
And/Or 2. You did put it in the code (and forgot to tell us in the question) but when you ran the batch file you hit the Enter key instead of typing an ID (say 1234).
What's happening is the result of these two mistakes:
jstack is supposed to be called with the id that you supply it.
But in your case (according to the code you supplied in the question) you called it without any variable. You wrote:
jstack > jstack.txt
So when you run jstack with no variable it outputs the following:
Terminate batch file Y/N?
Your second mistake is that you pressed Enter instead of giving a value when the program asked you: Enter ID:. If you would have put in an ID at this point, say 1234, the %id% variable would become that value, in our case 1234. But you did NOT supply a value and instead pressed Enter. When you don't give the variable any value, and if that variable was not set to anything else before, then the variable %id% is set to the prompt of the set command!! So now %id% is set to Enter ID: which was echoed on your screen as requested in the batch file BEFORE you called the jstack.
But I suspect you DID have the jstack %id% > jstack.txt in your batch file code with the %id (and omitted it by mistake from the question), and that you hit enter without typing in an id. The batch program then echoed the id, which is now "Enter ID:", and then ran jstack Enter ID: > jstack.txt
Jstack itself echoed the input, encountered a mistake and asked to terminate.
And all this was written into the jstack.txt file.
I have a little cmd I use when preparing pc to clients: it calls the user for input, and the rename the pc to that.
#ECHO "remember to run this as admin."
#ECHO OFF
SET /P _inputname= Please enter an computername:
#ECHO Du intastede "%_inputname%"
#ECHO "The pc will restart after this"
pause
#ECHO OFF
wmic computersystem where name="%COMPUTERNAME%" call rename name="%_inputname%"
shutdown -r -f
Dollar signs around the variable do not work on my Vista machine, but percent signs do.
Also note that a trailing space on the "set" line will show up between the prompt and user input.
Just added the
set /p NetworkLocation= Enter name for network?
echo %NetworkLocation% >> netlist.txt
sequence to my netsh batch job. It now shows me the location I respond as the point for that sample. I continuously >> the output file so I know now "home", "work", "Starbucks", etc. Looking for clear air, I can eavulate the lowest use channels and whether there are 5 or just all 2.4 MHz WLANs around.
Just to keep a default value of the variable. Press Enter to use default from the recent run of your .bat:
#echo off
set /p Var1=<Var1.txt
set /p Var1="Enter new value ("%Var1%") "
echo %Var1%> Var1.txt
rem YourApp %Var1%
In the first run just ignore the message about lack of file with the initial value of the variable (or do create the Var1.txt manually).
One other way which might be interesting. You can call a powershell script from where you can do pretty much anything, and send the data bach to cmd or do other stuff with something like this.
set var=myvar;
call "c:\input2.cmd" %var%.
Its kind of more flexible (You can send the data the same way with powershell).
So in your cmd, write this considering the ps script is in C::
PowerShell.exe -ExecutionPolicy unrestricted -Command "& {. C:\Input.ps1}"
And in your input.ps1 script, write this:
$var = Read-Host -Prompt "Your input"
Write-Host "Your var:",$var
#Do stuff with your variable