I have this simple batch file (test.bat):
echo %CD%
pause
No matter where I run this .bat file from (i.e. C:\some\dir\test.bat), my system tells me that I'm in C:\ . This is obviously neither the intended nor the desired behavior, and if I try the exact same script on a different machine, it behaves as expected, giving me current directory of the .bat file. I've been googling for hours now and haven't been able to find anything relevant to my issue. Perhaps I missed up a windows setting somewhere? I have no idea, anyone have any ideas?
Found the issue: there was an AutoRun registry entry that would change directory to C:\ whenever a shell was opened. facepalm
Background
I want to use ROBOCOPY to backup folders. To learn this, I created a test source folder, containing other subfolders and dummy files.
F:\RoboCopy\RoboCopy_Files
I am able to ROBOCOPY the source folder from the Command line and PowerShell (with using Windows 10).
ROBOCOPY "RoboCopy_Files" "RoboCopy_Files_Testing" /MIR
It does exactly what I want.
Now I put the command into batch file Robocopy.cmd.
Problem symptoms
However, when I put the same command into Robocopy.cmd file, in the root F:\RoboCopy folder and run it, I get only flashing cmd window with my command repeated on ever increasing number of lines.
How can I put the command into a CMD file (e.g. Robocopy.cmd) for later use/share/schedule? How to prevent command prompt from flashing in endless loop without running the command?
Note: I feel this is more about learning how to put cmd scripts into files, than how to use ROBOCOPY.
Cause: File and Command have the same name
I wanted to use the ROBOCOPY command inside the ROBOCOPY file. This is a mistake.
The file ends up calling itself.
Solution 1: Rename batch file
One solution is to rename the batch file to be different from the command(s) in the file.
Solution 2: Use more explicit command call
Another solution could be to use ROBOCOPY.exe or explicitly specify the full path to the exe like C:...\robocopy.exe. This would prevent the "confusion" in calling the command vs calling the batch file itself.
Solution 1 x 2
The best solution (thx Mofi again) is to combine the 1 x 2 together. Use unique batch file name AND specify the full path to command (exe) inside the batch file.
Useful related commands: To determine the full path to command (exe), see the WHERE command (e.g. Where Robocopy.exe - This should be somewhere in windows folder.), system variables (e.g. SS64), or the command SET.
The full version in my case would be to run for example BackupRobocopyFiles.cmd with line:
%SystemRoot%\System32\robocopy.exe "RoboCopy_Files" "RoboCopy_Files_Testing" /MIR /R:2
Note: This would work only if the cmd file is in the root folder F:\RoboCopy. If I would like to run the cmd from different folder (or task sheduler), I would specify the full path to SOURCE_FOLDER and DESTINATION_FOLDER parameters of ROBOCOPY command.
Contributions
The answer was found based on comments by: "MC ND", "eryksun". "Mofi" did point out, that the original Q was not helpful. Thanks to all.
I'm trying to launch an executable through a batch script. But my problem is that the executable requires a config file in the same directory as itself and instead it seems like the path to the batch file gets set to the current directory. So the executable looks for the configuration file in the batch's directory instead of it's own.
So far I've tried:
cd \\server\path\dir
programToRun.exe
and
start \\server\path\dir\programToRun.exe
but none of them seems to work.
From my one contribution to Wikipedia https://en.wikipedia.org/wiki/Batch_file#Setting_a_UNC_working_directory_from_a_shortcut
UNC default paths are turned off by default as they used to crash older programs.[10]
The Dword registry value DisableUNCCheck at HKEY_CURRENT_USER\Software\Microsoft\Command Processor[10] allows the default directory to be UNC. CD command will refuse to change but placing a UNC path in Default Directory in a shortcut to Cmd or by using the Start command. start "" /d \\127.0.0.1\C$ "cmd /k" (C$ share is for administrators).
Thanks for all the help but I was able to fix it by editing the C# code behind the executable.
I swapped out Directory.getCurrentDirectory() with System.Reflection.Assembly.GetEntryAssembly().Location.Replace("programToRun.exe", null)
I'm using Windows 7, and my problem is running this file from a console (cmd.exe):
W:\software\projects\myproject\build\msvc\build.bat
When I move into the folder containing the file manually and run it from there using the following command sequence, it works:
W:\>cd software
W:\software>cd projects
W:\software\projects>cd myproject
W:\software\projects\myproject>cd build
W:\software\projects\myproject\build>cd msvc
W:\software\projects\myproject\build\msvc>build.bat
However, when I try to run the file from the root directory in any of these ways:
W:\>software\projects\myproject\build\msvc\build.bat
W:\>call software\projects\myproject\build\msvc\build.bat
W:\>#call software\projects\myproject\build\msvc\build.bat
W:\>"software\projects\myproject\build\msvc\build.bat"
W:\>call "software\projects\myproject\build\msvc\build.bat"
W:\>#call "software\projects\myproject\build\msvc\build.bat"
I get the following error message:
The system cannot find the path specified.
I'm pretty sure you didn't have to navigate to the folder containing the file in order to run it when I was using Windows XP (though I could be wrong, of course), but this apparently seems to be the case with Windows 7. Or am I missing something?
You are correct. You do not need to navigate to the batch scripts folder before executing.
The error "The system cannot find the path specified." is most likely caused by something inside your batch-file.
Try to add
cd W:\software\projects\myproject\build\msvc
w:
or in a single command (as suggested by James K, Thanks!)
cd /d W:\software\projects\myproject\build\msvc
Searched a bit more and found this generic solution:
cd /d %~dp0
at the top of your batch file to set the working directory to the directory of the script to check whether this is the cause.
If you execute your file from W:\ this is where the commands are executed (working directory). It is most likely that your script cannot find some file it uses in this location.
I am trying to run a batch file from a network share, but I keep getting the following message: "UNC path are not supported. Defaulting to Windows directory." The batch file is located on \\Server\Soft\WPX5\install.bat. While logged in as administrator, from my Windows 7 Desktop, I navigate to \\Server\Soft\WP15\ and double click on install.bat, that's when I get the "UNC path are not supported." message. I found some suggestions online stating that mapping drive will not work, but using a symbolic link will solve this issue, but the symbolic link didn't work for me. Below is my batch file content, I would appreciate any assistance that can help me accomplish what I am trying to do. Basically, I want to be able to run the batch file from \\Server\Soft\WP15\install.bat.
Batch file content
mklink /d %userprofile%\Desktop\WP15 \\server\soft\WP15
\\server\soft\WP15\setup.exe
robocopy.exe "\\server\soft\WP15\Custom" /copyall "C:\Program Files (x86)\WP\Custom Templates"
Regedit.exe /s \\server\soft\WPX5\Custom\Migrate.reg
Also, how do I remove the symbolic link after the install is completed?
PUSHD and POPD should help in your case.
#echo off
:: Create a temporary drive letter mapped to your UNC root location
:: and effectively CD to that location
pushd \\server\soft
:: Do your work
WP15\setup.exe
robocopy.exe "WP15\Custom" /copyall "C:\Program Files (x86)\WP\Custom Templates"
Regedit.exe /s WPX5\Custom\Migrate.reg
:: Remove the temporary drive letter and return to your original location
popd
Type PUSHD /? from the command line for more information.
I feel cls is the best answer. It hides the UNC message before anyone can see it. I combined it with a #pushd %~dp0 right after so that it would seem like opening the script and map the location in one step, thus preventing further UNC issues.
cls
#pushd %~dp0
:::::::::::::::::::
:: your script code here
:::::::::::::::::::
#popd
Notes:
pushd will change your working directory to the scripts location in the new mapped drive.
popd at the end, to clean up the mapped drive.
There's a registry setting to avoid this security check (use it at your own risks, though):
Under the registry path
HKEY_CURRENT_USER
\Software
\Microsoft
\Command Processor
add the value DisableUNCCheck REG_DWORD and set the value to 0 x 1
(Hex).
Note:
On Windows 10 version 1803, the setting seems to be located under HKLM:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
Basically, you can't run it from a UNC path without seeing that message.
What I usually do is just put a CLS at the top of the script so I don't have to see that message. Then, specify the full path to files in the network share that you need to use.
I needed to be able to just Windows Explorer browse through the server share, then double-click launch the batch file. #dbenham led me to an easier solution for my scenario (without the popd worries):
:: Capture UNC or mapped-drive path script was launched from
set NetPath=%~dp0
:: Assumes that setup.exe is in the same UNC path
%NetPath%setup.exe
:: Note that NetPath has a trailing backslash ("\")
robocopy.exe "%NetPath%Custom" /copyall "C:\Program Files (x86)\WP\Custom Templates"
Regedit.exe /s %NetPath%..\WPX5\Custom\Migrate.reg
:: I am not sure if WPX5 was typo, so use ".." for parent directory
set NetPath=
pause
Instead of launching the batch directly from explorer - create a shortcut to the batch and set the starting directory in the properties of the shortcut to a local path like %TEMP% or something.
To delete the symbolic link, use the rmdir command.
I ran into the same issue recently working with a batch file on a network share drive in Windows 7.
Another way that worked for me was to map the server to a drive through Windows Explorer: Tools -> Map network drive. Give it a drive letter and folder path to \yourserver. Since I work with the network share often mapping to it makes it more convenient, and it resolved the “UNC path are not supported” error.
My situation is just a little different. I'm running a batch file on startup to distribute the latest version of internal business applications.
In this situation I'm using the Windows Registry Run Key with the following string
cmd /c copy \\serverName\SharedFolder\startup7.bat %USERPROFILE% & %USERPROFILE%\startup7.bat
This runs two commands on startup in the correct sequence. First copying the batch file locally to a directory the user has permission to. Then executing the same batch file. I can create a local directory c:\InternalApps and copy all of the files from the network.
This is probably too late to solve the original poster's question but it may help someone else.
This is the RegKey I used:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor]
"DisableUNCCheck"=dword:00000001
My env windows10 2019 lts version and I add this two binray data ,fix this error
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor DisableUNCCheck value 1
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Command Processor
DisableUNCCheck value 1
This is a very old thread, but I still use Windows 7. :-)
There is one point that no one seems to have taken into account, which probably would help Windows 10 users also.
If Command Extensions are enabled, the PUSHD command accepts network paths in addition to the normal drive letter and path.
So the obvious - and simplest - answer might be to enable command extensions in the batch script, if you intend to use PUSHD. At the very least, this ought to reduce the problems you might have in using PUSHD wqith a network path.
I stumbled upon this question while searching for a solution to a specific problem. I needed to make a batch script that sits in a network folder (UNC path) with a Python script. The goal was to be able to double click on the batch script and have it run the Python script:
with the network folder containing the script as the working directory,
without modifications to the Python script (no command line parameters or hard-coded paths).
without creating another Python file.
The pushd and popd solutions were unsatisfactory. They work, but if the user were to get in the habit of forcefully terminating the script while it was running, they would end up with a bunch of mapped drives in My Computer since popd wasn't run.
I start by using cls to clear the UNC path error. I then assign the path containing the batch script to a variable. I slice the path to remove the trailing backslash (otherwise, Python throws a SyntaxError). Finally, I run a couple Python commands inside the batch file that change the working directory and execute the target script:
cls
#echo off
set pyfile=myscript.py
set batchdir=%~dp0
set wdir=%batchdir:~0,-1%
python -c "import os; import runpy; os.chdir(r""%wdir%""); runpy.run_path(r""%pyfile%"")"
pause
Editing Windows registries is not worth it and not safe, use Map network drive and load the network share as if it's loaded from one of your local drives.