I've searched in many posts that already deal with this kind of issue but I'm still not able to make it work in my case.
I'm trying to create a link file to Launch a bat file with cmd.exe (because the bat file launch a service in spy/console mode so the console has to be shown).
The bat file is created before the install process of the service.
The link file is created in Windows Start Menu while installing process, so it can embed the path where the exe file of the service is installed.
As the root path will be linked to cmd.exe, I need to pass the path of the exe of the service as an argument of the bat file, itself being an argument of the cmd.exe file...
I've tried the syntax given as a solution in this threat :
correct quoting for cmd.exe for multiple arguments
Spaces in Program Path + parameters with spaces :
cmd /k ""c:\batch files\demo.cmd" "Parameter 1 with space" "Parameter2 with space""
So in my case, I've writen:
cmd /k ""C:\Program Files (x86)\Company\Licenses Server\Debug Mode.bat" "C:\Program Files (x86)\Company\Licenses Server\""
Here is the content of the "Debug Mode.bat" file :
#ECHO off
net stop company.service
START %~f1ServiceFile.exe /console spymode
net start company.service
#ECHO On
But when I launch the link file, I get the message:
Windows cannot find C:\Program...
There must be a "quote" problem but I've tried a lot of different syntaxes and I cannot figure out what goes wrong here...
Related
I'm writing a .bat file to launch two programs, not having success so far. I've followed the guide here.
#echo off
cd "D:\CRCR 0.4.0\"
start "" "D:\CRCR 0.4.0\Chernobyl Relay Chat Rebirth.exe"
cd "D:\MO2\"
start "" "D:\MO2\ModOrganizer.exe moshortcut://:Anomaly Launcher"
exit
Whenever I try to launch the batch file, it tells me "Windows cannot find 'D:\MO2\ModOrganizer.exe "moshortcut://:Anomaly Launcher'. Make sure you've typed the name correctly, then try again."
I've tried removing 'start' from those lines, removing quotations from the cd lines, etc. How can I get this working?
You probably want to pass moshortcut://:Anomaly Launcher as a parameter.
In that case you should also separate the string:
start "" "D:\MO2\ModOrganizer.exe" "moshortcut://:Anomaly Launcher"
Otherwise Windows will interpret the path as D:\MO2\ModOrganizer.exe moshortcut://:Anomaly Launcher not D:\MO2\ModOrganizer.exe and assume that the entire string is part of the path.
Simply put, I have a VBScript titled "tyrian_soundtest.vbs" that plays an .mp3 that is titled "tyrian_soundtest.mp3"
The VBScript code is below
Set Sound = CreateObject("WMPlayer.OCX.7")
Sound.URL = "tyrian_soundtest.mp3"
Sound.Controls.play
do while Sound.currentmedia.duration = 0
wscript.sleep 1
loop
wscript.sleep (int(Sound.currentmedia.duration)+1)*1000
When opened, it plays the .mp3. Simple enough.
The trouble comes in when I run a batch script titled "tyrian_soundtest.bat". Relative to it, the .vbs and .mp3 are in a folder called sfx. Here is what one iteration of that file contained.
#echo off
start %cd%\sfx\tyrian_soundtest.vbs
exit /b
The result is an error stating that Windows couldn't find the file path, likely due to it containing a space. Other attempts of the .bat were replacing line 2 with
start .\sfx\tyrian_soundtest.vbs
or
start "%cd%\sfx\tyrian_soundtest.vbs"
Any attempt I've made gives one of three results. Option 1: There is no error, but the audio simply never plays. Option 2: An error is thrown about the file directory not being found. Option 3: That file path opens up in a new cmd window, but the .vbs is never run.
Is there any way format the .bat to get the .vbs to run through the without an error being caused?
The main issue is that there is used in batch file and in the VBScript file the current directory path. The current directory on starting %SystemRoot%\System32\cmd.exe to process the batch file can be any directory.
The Windows Explorer sets the directory of the batch file as current directory on double clicking the batch file resulting in starting cmd.exe by explorer.exe to process the double clicked batch file of which full qualified file name is passed to cmd.exe after the option /c as additional argument. But if the batch file is stored on a network resource accessed using UNC path, the Windows command processor changes the current directory from the network resource to %SystemRoot% (the Windows directory) and the batch file fails to start Windows Script Host to process the VBS file. See also: CMD does not support UNC paths as current directories.
A batch file can be also started by right clicking on it and using Run as administrator. This can result in making the directory %SystemRoot%\System32 (the Windows system directory) the current directory. See also: Why does 'Run as administrator' change (sometimes) batch file's current directory?
That are just two of many examples where the current directory is different to the directory containing the batch file. So if a batch file references other files stored in same directory as the batch file itself or a subdirectory of the batch files directory, it is advisable to reference these files with the full path of the batch file instead of using a path relative to current directory.
Example:
The used files are stored in directory C:\Temp\Development & Test as follows:
sfx
tyrian_soundtest.vbs
tyrian_soundtest.mp3
tyrian_soundtest.bat
A user opens a command prompt window which usually results in making the directory referenced with %USERPROFILE% or with %HOMEDRIVE%%HOMEPATH% the current directory. A user executes next in the command prompt window:
"C:\Temp\Development & Test\tyrian_soundtest.bat"
So the current directory is definitely not the directory containing the batch file.
The batch file can be coded as follows to start nevertheless the Windows Script Host for processing the VBS file tyrian_soundtest.vbs and successfully play the MP3 file tyrian_soundtest.mp3.
#start "" /D "%~dp0sfx" %SystemRoot%\System32\wscript.exe //NoLogo "%~dp0sfx\tyrian_soundtest.vbs"
%~dp0 references the drive and path of argument 0 which is the full path of the currently processed batch file. The batch file path referenced with %~dp0 always ends with a backslash. For that reason the concatenation of %~dp0 with a file/folder name or wildcard pattern should be always done without using an additional backslash as that would result in two \ in series in complete argument string and the Windows file management would need to fix that small error by replacing \\ by just \ before passing the argument string to the file system. See also the Microsoft documentation about Naming Files, Paths, and Namespaces which explains which automatic corrections are usually applied on file/folder strings before passing them to the file system.
The internal command START of cmd.exe interprets the first double quoted argument string as title string for the console window as it can be seen on running in a command prompt window start /? and reading the output help. For that reason it is not enough to use just:
#start "%~dp0sfx\tyrian_soundtest.vbs"
That would result in starting one more command process with its own console window with the full qualified file name of the VBS file as title of the console window.
The Windows Script Host processing a VBS file by default on Windows exists in two versions:
%SystemRoot%\System32\cscript.exe is the console version.
%SystemRoot%\System32\wscript.exe is the Windows GUI version.
The usage of the console version cscript.exe results usually in opening a console window by the parent process if the parent process is not itself a console application running already with an opened console window like on execution of a batch file processed by %SystemRoot%\System32\cmd.exe being also a console application.
The usage of the Windows GUI version wscript.exe results in no opening of a window by default at all. The processed script file must contain commands to open a window if that is wanted at all.
The difference can be also seen on running from within a command prompt window cscript /? and next wscript /?. The first command results in printing the help for the command line options of Windows Script Host in already opened command prompt window while the second command results in showing a graphic window by wscript.exe displaying the same usage help.
The usage help of Windows Script Host explains also how each user can define which version of Windows Script Host is the default for executing scripts. So it is not advisable to specify just the VBS file name with full path on the command line with start and let cmd.exe look up in Windows registry which version of Windows Script Host to run to process the VBS file. It is better to explicitly run the version of Windows Script Host most suitable for playing the MP3 file which is in this case the Windows GUI version wscript.exe opening by default no window at all to play the MP3 file in background.
So it would be possible to use:
#start "" %SystemRoot%\System32\wscript.exe //NoLogo "%~dp0sfx\tyrian_soundtest.vbs"
There is an empty title string defined with "" as the started executable wscript.exe is a Windows GUI application for which no console window is opened at all by cmd.exe. So the title string does not really matter and can be an empty string.
But there is left one problem with that command line. The VB script references the MP3 file without path which means with a path relative to current directory. The current directory is %USERPROFILE% and not C:\Temp\Development & Test\sfx which contains the MP3 file tyrian_soundtest.mp3. So the VB script would fail to find the MP3 file to play.
There are two solutions to fix this:
The usage of the following command line in the batch file:
#start "" /D "%~dp0sfx" %SystemRoot%\System32\wscript.exe //NoLogo "%~dp0sfx\tyrian_soundtest.vbs"
The option /D of command START is used to explicitly set the subdirectory sfx of the batch file directory as start in respectively current directory for the process wscript.exe which cmd.exe starts using the Windows kernel library function CreateProcess with an appropriate created structure STARTUPINFO.
The VBS file references the MP3 file tyrian_soundtest.mp3 with its full path which the VB script file determines itself from its own full qualified file name. That can be achieved in the VB script file tyrian_soundtest.vbs by using in the second line:
Sound.URL = CreateObject("Scripting.FileSystemObject").GetParentFolderName(WScript.ScriptFullName) + "\tyrian_soundtest.mp3"
Best would be using both possible solutions as in this case the VB script file would work also on being executed by a different process than cmd.exe processing the batch file tyrian_soundtest.bat and deletion of directory %~dp0sfx is not possible as long as started wscript.exe is running because of this directory is the current directory of running Windows Script Host.
So the batch file as well as the VB script file work now both independent on which directory is the current directory as both reference the files with full path determined by the scripts themselves from their full qualified file names.
Whenever I try and run mycommand.exe from my Windows cmd.exe terminal, I get this error:
''mycommand.exe' is not recognized as an internal or external command, operable program or batch file'
Secondly
I've also experienced a similar error when I tried to run C:\Program Files\My-App\Mobile.exe
''C:\Program' is not recognized as an internal or external command, operable program or batch file'
This is a very common question seen on Stackoverflow.
The important part here is not the command displayed in the error, but what the actual error tells you instead.
a Quick breakdown on why this error is received.
cmd.exe Being a terminal window relies on input and system Environment variables, in order to perform what you request it to do. it does NOT know the location of everything and it also does not know when to distinguish between commands or executable names which are separated by whitespace like space and tab or commands with whitespace as switch variables.
How do I fix this:
When Actual Command/executable fails
First we make sure, is the executable actually installed? If yes, continue with the rest, if not, install it first.
If you have any executable which you are attempting to run from cmd.exe then you need to tell cmd.exe where this file is located. There are 2 ways of doing this.
specify the full path to the file.
"C:\My_Files\mycommand.exe"
Add the location of the file to your environment Variables.
Goto:
------> Control Panel-> System-> Advanced System Settings->Environment Variables
In the System Variables Window, locate path and select edit
Now simply add your path to the end of the string, seperated by a semicolon ; as:
;C:\My_Files\
Save the changes and exit. You need to make sure that ANY cmd.exe windows you had open are then closed and re-opened to allow it to re-import the environment variables.
Now you should be able to run mycommand.exe from any path, within cmd.exe as the environment is aware of the path to it.
When C:\Program or Similar fails
This is a very simple error. Each string after a white space is seen as a different command in cmd.exe terminal, you simply have to enclose the entire path in double quotes in order for cmd.exe to see it as a single string, and not separate commands.
So to execute C:\Program Files\My-App\Mobile.exe simply run as:
"C:\Program Files\My-App\Mobile.exe"
When you want to run an executable file from the Command prompt, (cmd.exe), or a batch file, it will:
Search the current working directory for the executable file.
Search all locations specified in the %PATH% environment variable for the executable file.
If the file isn't found in either of those options you will need to either:
Specify the location of your executable.
Change the working directory to that which holds the executable.
Add the location to %PATH% by apending it, (recommended only with extreme caution).
You can see which locations are specified in %PATH% from the Command prompt, Echo %Path%.
Because of your reported error we can assume that Mobile.exe is not in the current directory or in a location specified within the %Path% variable, so you need to use 1., 2. or 3..
Examples for 1.
C:\directory_path_without_spaces\My-App\Mobile.exe
or:
"C:\directory path with spaces\My-App\Mobile.exe"
Alternatively you may try:
Start C:\directory_path_without_spaces\My-App\Mobile.exe
or
Start "" "C:\directory path with spaces\My-App\Mobile.exe"
Where "" is an empty title, (you can optionally add a string between those doublequotes).
Examples for 2.
CD /D C:\directory_path_without_spaces\My-App
Mobile.exe
or
CD /D "C:\directory path with spaces\My-App"
Mobile.exe
You could also use the /D option with Start to change the working directory for the executable to be run by the start command
Start /D C:\directory_path_without_spaces\My-App Mobile.exe
or
Start "" /D "C:\directory path with spaces\My-App" Mobile.exe
when you have this problem
search for Environment variables
press on Environment variables
Under "System varibles" you search for PATH and press edit
press on new and add the path of your program and save it
I am writing a batch file on my Windows 8.1 machine. In one section of my batch file I need to start a command prompt in the "current working directory".
So far, this is what my batch file looks like:
#echo OFF
set WORKING=%cwd%
start cmd.exe /K pushd %WORKING%
exit
Let's say the batch file is located in the folder C:\Temp\Utilities. If I open an explorer window and double click the batch file to run it everything works great. A new command prompt is created in the directory C:\Temp\Utilities. However, if I right-click the batch file and select Run as administrator the working directory is no longer the location of the batch file, it's C:\Windows\System32.
Similarly, if I create a shortcut to the batch file in a different folder (for example. C:\Temp) and repeat the two steps above the results are the same. If I double click the shortcut and run it as a normal user the working directory is what I would expect. (Note, the working directory for the shortcut it's whatever is set for "Start in" of the shortcut properties, not the location of the batch file.) If I right click the shortcut and run it as administrator I again get a command prompt opened to the folder C:\Windows\System32.
I assume this is a "bug" or "feature" (if you want to call it that) in Windows 8.1 and it probably happens because execution environments for programs run as administrator are forced to run in the System32 folder? (I remember with Windows 7 this did not happen so it must be a new feature to Windows 8.)
I found one way to fix the issue and stop the command prompt from starting in C:\Windows\System32. I did this by modifying the following line in the batch file:
set WORKING=%~dp0
Doing it this way sets the working directory to the location of the batch file. With this change, no matter how I run the batch file or the shortcut (administrator or normal) the working directory ends up being the same, C:\Temp\Utilities.
The problem with this solution is I don't want the working directory to always be the location of the batch file. If the batch file is run directly then it's okay but if I run it from a shortcut I need the working directory to be whatever is set in the "Start in" property of that shortcut. For example, if the batch file is located in the folder D:\Temp\Utilities this is what I need to happen regardless of whether I run as administrator or not:
Shortcut Location Start In Property Command Prompt Working Directory
-------------------- ------------------- ------------------------------------------
C:\Temp <undefined> D:\Temp\Utilities
C:\Data\bin C:\Data\bin C:\Data\bin
C:\Data\bin D:\Temp\Utilities D:\Temp\Utilities
What this means is I can't always use %~dp0 to set the working directory in my batch file. What I need is some way for the batch file to know if it was run either directly or by a shortcut. If the batch file is run directly then the working directory is easy to get, it's just the value of %cwd%. If the batch file is run by using a shortcut, I don't know how to get the "Start in" property inside the batch file.
Does anyone know how I can do these two things inside my batch file:
1. Check whether it was run directly or by a shortcut.
2. If run by a shortcut, get the "Start in" property of the shortcut that started it.
Thank you,
Orangu
UPDATE
I found sort-of a "hackish" way to fix the issue. For the shortcut I edited the "Target" field and changed it to the following:
cmd.exe /k pushd "C:\Temp" && "D:\Temp\Utilities\batchfile.bat"
Now the working directory can be obtained by calling %CD% in the batch file and this works for both administrator and normal users. It does not, however, work for the case when I run the batch file directly. I still need to use %~dp0 in that case.
I don't like this solution, however, because it requires me to manually change all shortcuts I make and it also makes the icon look like a cmd prompt icon rather than a batch file.
Have you already considered to not use shortcuts at all?
You could e.g. create a batchfile_exec.bat containing your call
REM optionally do
REM cd /D working_directory
REM if you want to force a special working directory
D:\Temp\Utilities\batchfile.bat
and replace all the shortcuts with batchfile_exec.bat. If you double-click batchfile_exec.bat, the working directory will be the one containing batchfile_exec.bat.
I personally don't like Windows shortcuts that much, because they are hard to handle within a revision control system. As you also noticed, it is very time consuming if you want to modify a lot of them.
By the way: If batchfile.bat was designed/written to be always run from the direcory where it is located, you might also consider to modify batchfile.bat to force that behaviour:
setlocal
cd /D %0\..
REM your original content
endlocal
In %0 the path to the batchfile is stored.
The trick is to assume that %0 is a directory and then to change one level lower based on that directory. With /D also the drive letter is changed correctly.
The cd command doesn't care if %0 is really a directory. In fact %d doesn't even have to exist (%0\dummy\..\.. would also work).
The setlocal command is to have the working directory being restored when batchfile.bat has finished (this would be good if batchfile.bat was called form another batch file).
I noticed that the endlocal command is not really necessary in this context since it is applied implicitly when batchfile.bat finishes.
I'm writing a .bat file to handle some script generation automatically so I don't have to type in half a dozen command arguments each time I want to run it.
I have to run a vb script from the batch file
#call ..\Database\scripts\runscriptupdates.vbs
However the script will only run if using the the command prompt from
C:\Windows\SysWOW64\cmd.exe
By default the bat file uses the cmd.exe in system32
C:\Windows\System32\cmd.exe
Is there a way to force the batch file to use this cmd.exe to run the vbs file? I've been trawling the web for about an hour now and haven't found anything which helps (so far).
I've tried running the syswow64 with "start ..." however it doesn't seem to take the arguments after it.
Many thanks, Neil
You can try:
%windir%\SysWoW64\cmd.exe /c mybatch.bat
This will run the batch itself from a 32-bit command prompt. Thus, the call to your vbs will also be coming from a 32-bit command prompt.
I also had this problem, and I found the way to solve it.
You just need to change System Variables.
Go to Control Panel » System » Advanced System Settings » Environment Variables.
Find the variable ComSpec, then just click Edit... and change the path to "C:\Windows\SysWow64\cmd.exe"
Try typing this one line in your batch file.
%windir%\SysWoW64\cmd.exe /c ["]cscript [script name] [host options] [script arguments]["]
Where:
script name is the name of the script file, including the file name extension and any necessary path information.
host options are the command-line switches that enable or disable various Windows Script Host features. Host options are always preceded by two slashes (//).
script arguments are the command-line switches that are passed to the script. Script arguments are always preceded by one slash (/).
Example:
%windir%\SysWoW64\cmd.exe /c "cscript VoltageDrop.vbs /"Campbell.sin" "L08""
Note: In this line I do not pass any host options. This command will execute the string,
cscript VoltageDrop.vbs /"Campbell.sin" "L08"
as a command in the 32-bit command prompt.