Firstly, I've seen this.
Now, I would like to open a file which has unregistered extension in the program which is not installed in windows, all via batch.
START "%~dp0\arch\file.nesta" "%~dp0\Virtua.exe"
rem this will open only program
pause
START "" "%~dp0\arch\file.nesta" "%~dp0\Virtua.exe"
rem and this will summon "Open in program" win window
Point is to drop a file into program with one (double) click.
(exe file and bat file ar in same folder while file is in "arch" subfolder)
Syntax for command START
Squashman has given already the (nearly) right answer which I explain here in more details.
Running in a command prompt window start /? displays help for this command also described by Microsoft on page about command start with entire command line reference in menu on left side.
After command START there should be specified the "title for command window" in double quotes. This can be also an empty string specified with "" if the application to start is a GUI application and not a command or console application. The title of the GUI window is always defined by the GUI application and not by command processor. So a meaningful title string instead of an empty title string makes sense only for console applications and commands of Windows command processor executed in a new console window.
A title string in double quotes is not necessary if there is no string on entire line enclosed in double quotes because no parameter string contains a space or a character from this list: &()[]{}^=;!'+,`~ This character list is displayed at end of last output help page on running in a command prompt window cmd /?
Then one or more of the optional parameters of START itself must be specified on the line if one of those parameters is required for the task at all.
The next parameter must be the command or application to run as new process. START can be also used to just start a new command process with a new console window and therefore a command or application must not be specified. But START is used in in batch file usually to run an application in a separate process and not for just opening a new command prompt window.
And last are specified the parameters of the command or application to start.
What does this mean in practice?
Command START with one parameter in quotes
START "%~dp0\arch\file.nesta"
Command START creates in this case a new command process with Drive and path of batch file\arch\file.nesta as title for the new console window displayed in title bar of the window. So the single string in double quotes is interpreted by command START always as title string for a new command window.
Command START with two parameters in quotes in wrong order
START "%~dp0\arch\file.nesta" "%~dp0\Virtua.exe"
This results in starting Virtua.exe in directory of batch file with Drive and path of batch file\arch\file.nesta as title for the new console window in case of Virtua.exe is a console application.
But even if Virtua.exe is a GUI application, the string %~dp0\arch\file.nesta is already taken by command START as window title not being displayed anywhere and therefore Virtua.exe is always started with no parameter using this command line.
Command START with two parameters in quotes in right order with missing required title string
START "%~dp0\Virtua.exe" "%~dp0\arch\file.nesta"
This results (most likely) in an error message as Drive and path of batch file\Virtua.exe is interpreted as title and command processor can't find in directory Drive and path of batch file\arch a file with name file.nesta.* with a file extension listed in environment variable PATHEXT.
Command START with two parameters in quotes in right order and with required title string
START "" %~dp0Virtua.exe" "%~dp0arch\file.nesta"
This is the right command to start Virtua.exe in directory of batch file with file.nesta in subfolder arch of batch file folder as parameter for Virtua.exe and given the console window no title if Virtua.exe is a console application.
There is no backslash after %~dp0 as this string is expanded by command processor always to drive and path of batch file ending already with a backslash before command START processes the parameters.
Using %~dp0\ would result in \\ between path of batch file folder and for example Virtua.exe which is not 100% correct. However, Windows automatically cleans up file and folder strings with \\ inside and therefore this small mistake would have no effect on execution.
Summary
On specifying ALWAYS first a title string in double quotes after START makes your batch coding life easier.
Using "" for a GUI application and "Something meaningful" for a command or console application as title string makes it easier for the users of the batch file to identify what the opened console window is for in list of running applications displayed on using Alt+Tab, in Windows task bar depending on the used task bar options (just symbol displayed or symbol with begin of window title) and in Task Manager of Windows.
Note:
There are combinations of not quoted parameters and quoted parameters which do not require a quoted title string. But it is really much easier to specify always a title string instead of finding out when a title string in quotes must be specified and when it is possible to omit it if any parameter is enclosed in quotes.
Related
My code in the .bat looks like this.
"C:\users\reshade injector.exe"
C:\pathtogame\game.exe "added argument"
"c:\users\reshade injector.exe" <- if I open the actual file, it opens a command window and waits for my other application to launch. Is this a console app?
C:\pathtogame\game.exe "added argument" <- this works and launches my game
Another issue is that when launching the first .exe, a command window stays open. How do I make the command window not appear?
Can anyone help me with these two problems?
*edit for clarity
by opening the actual file, I mean double-clicking on the original reshade injector.exe.
When opening reshade injector.exe, two cmd windows open. They close as soon as I launch the game.exe.
I can't seem to get the reshade injector.exe to launch through the .bat file.
Batch will run any application it finds. If the application does not terminate (eg. it's waiting for user-input) then it will progress to the next instruction.
Some applications work by launching another (the user-interface) and then terminating, leaving the second application resident.
There's no way to tell without observing which approach any random application may take.
So - your batch should execute a file named c:\users\reshade injector.exe.
You say that "fails". Is there an error message generated? You would likely need to run the batch from the "command prompt" to see that message. Note that the Space between reshade and injector must be in the actual filename. If injector.exe is a file in a subdirectory called reshade, then you need a backslash between reshade and injector.
Having resolved the actual name of the first executable, try
#echo off
setlocal
start "" "firstexecutablename"
start "" "secondexecutablename" "arguments"
The first two lines prevent "command echoing" which is used for debugging and establish a "local environment" which ensures the "environment" for the batch file remains unchanged when the batch terminates. In the current case, these two lines are probably unnecessary, but it's SOP for batch files.
The batch should then close its session and window once it has attempted to launch the two applications.
The "" following start becomes the window-title. It can be any quoted string you like, but should not be omitted as start uses the first quoted string it finds as a window-title and may not recognise it as part of the executable/arguments.
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.
I have made a batch file which contains personal data, so to hide it from other people and to post it, I decided to "encrypt" it converting it to exe via IExpress.
My batch file is named prime.bat and it is located in %userprofile%.
Here are the steps I ran with iexpress.exe:
Runned iexpress.exe.
Selected Create new Self Extraction Directive file
Selected Extract files and run an installation command.
Entered package title (Prime finder).
Selected No prompt..
Selected Do not display a license..
Selected prime.bat located in %userprofile% (C:\Users\%username%).
Entered cmd /c prime.bat in Install Program and left Post Install Command as is (<None>).
Selected Default (recommended).
Selected No message.
Entered C:\Users\username\prime.exe and did not check any of boxes below.
Selected No restart.
Selected to save SED file.
Package created successfully!
As the batch file works with arguments, it must be run from the cmd. When I clicked the file single from explorer it opened correctly. Because I had put an error message if there are no arguments, it threw expected error and exited with 1. If I type just prime.exe in cmd, the above happens, and same output is produced.
But, if I run file from cmd again, but specify arguments, I get an error message in a new window. As I don't use English language and do not have the permissions to change language, I will try to translate the output:
Syntax error appeared in command line's selections.
Type /? after the command for help.
So, I typed prime.exe /?, and a new window with help appeared. I think I am missing something in iexpress.exe options.
I solved my problem using:
prime.exe /c:"cmd /c prime.bat numeric_arguments"
Which should be used when you want to send arguments to an IExpress 'compiled' file as /c option specifies a new install command.
I try this code :
start /d "D:\test\CONTOH\DATA\QGIS2\bin\" qgis.bat
based on :
Bat file to run a .exe at the command prompt
But, I want to be relative path, something like this :
start /d %~dp0\DATA\QGIS2\bin\qgis.bat
based on :
relative path in BAT script
but, nothing happen. So, can someone give me information, what is wrong?
Open a command prompt window and run start /?. This outputs the help for the command START which should be read on using this command to get knowledge about its options.
Run in command prompt window call /? and read the output help pages to understand %~dp0. The drive and path of the batch file (argument 0) always ends with a backslash. Therefore don't add an extra backslash on concatenating it with another string.
And the first double quoted string is interpreted by START as title for the new console window displayed in title bar of the new window. Therefore better specify always a title string which can be also an empty string like "" in case of starting a GUI application on which no console window is opened at all.
start "Running QGIS2" /D "%~dp0DATA\QGIS2\bin" qgis.bat
Also possible is using this command line in batch file:
start "Running QGIS2" /D"%~dp0DATA\QGIS2\bin" qgis.bat
Here start in directory as defined with /D"%~dp0DATA\QGIS2\bin" is 100% correct specified according to help of command START as one parameter string.
But Windows command interpreter accepts also the first variant with just option /D without any folder path and next parameter string "%~dp0DATA\QGIS2\bin" after a separating space is the folder path for start in directory.
The first variant with just /D as one parameter string and "%~dp0DATA\QGIS2\bin" as one more parameter string is easier to read in comparison to second variant with /D"%~dp0DATA\QGIS2\bin" being just one parameter string.
I am trying to create a batch file which runs an exe from a specific path.
Eg: I have my exe in E drive. Exact path is E:\kk.exe. I want to run this kk.exe from D:\bin folder.
I use the following command in my batch file:
start "D:\bin" "E:\kk.exe"
So far no luck. Any help would be appreciated.
start "" /d "d:\bin" "e:\kk.exe"
start command has a peculiar behaviour: the first quoted argument is the title of the window. That is the reason for the initial "" (you can include the title you want). The rest of the line is the starting folder (/d, what will be the current active folder for the started process) and the command to execute.
cd /d "D:\bin"
start "window name" "E:\kk.exe"
If I've decoded your meaning correctly, you wish to run kk.exe while your current directory is d:\bin. This will create an independent process to run that program.
Note: the syntax of "start" is such that it's advisable to assign a window title (the first quoted parameter) - if you don't ant a title, leave the text out and use en empty quoted string.
However, if you just want to execute e:\kk.exe then
cd /d "D:\bin"
"E:\kk.exe"