I am a streamer and I need a few programs to stream. It's annoying to open all of them so I tried putting them in a batch file. I looked up the process and followed it,but every time I run the batch file it comes back invalid.
This is what my batch file looks like:
#echo off
cd C:\Program Files "(x86)\obs-studio\bin\64bit"
start obs64.exe
#echo off
cd "C:\Program Files\HexChat"
start hexchat.exe
#echo off
cd "C:\Program Files (x86)\Nightbot"
start nightbot.exe
exit
Cmd gives me an error saying it cannot find the file. When I put this into cmd by itself it opens the program.
Also is there a way to add applications from chrome to the file?
Open a command prompt window and run from within this window start /? which outputs the help for this command and explaining all options.
Following batch file most likely works:
#echo off
start "" "%ProgramFiles(x86)%\obs-studio\bin\64bit\obs64.exe"
start "" "%ProgramFiles%\HexChat\hexchat.exe"
start "" "%ProgramFiles(x86)%\Nightbot\nightbot.exe"
This batch file starts the three applications with current directory on execution of the batch file being also the current directory for the 3 started applications.
But the following batch file should be used if it is really necessary that each application is started with the application's directory as current directory:
#echo off
start "" /D"%ProgramFiles(x86)%\obs-studio\bin\64bit" obs64.exe
start "" /D"%ProgramFiles%\HexChat" hexchat.exe
start "" /D"%ProgramFiles(x86)%\Nightbot" nightbot.exe
With parameter /D and path of application's folder the Start In directory is set first like when using command CD. So for example hexchat.exe is started with current directory being C:\Program Files\HexChat for this application.
The two double quotes after command START are necessary as this command interprets first double quoted string as title for the process. By using "" an empty title string is explicitly specified resulting in rest of command line being correct interpreted as expected. I suppose those three applications are all GUI applications and not console applications and therefore a real title string being useful on running a console application in an new command process for the console window is not really necessary.
%ProgramFiles% references the predefined environment variable ProgramFiles containing path to standard program files folder for 64-bit applications on 64-bit Windows when batch file is started with 64-bit cmd.exe as default on 64-bit Windows and is replaced by Windows command interpreter before execution of the command line on your Windows computer by C:\Program Files.
%ProgramFiles(x86)% references the predefined environment variable ProgramFiles(x86) containing always path to standard program files folder for 32-bit applications on 64-bit Windows and is replaced by Windows command interpreter before execution of the command line on your Windows computer by C:\Program Files (x86).
It is of course also possible to use the real paths in your computer instead of the environment variable references if this batch file is never shared with other people.
Extra hint:
Run in a command prompt window the command you want to use with /? as parameter to get displayed the help for this command. Other sources for help on commands and predefined environment variables displayed all on running in a command prompt window set are:
SS64.com - A-Z index of the Windows CMD command line
Microsoft's command-line reference
Windows Environment Variables and WOW64 Implementation Details
Related
I have a Windows machine with the current user in C:\Users\User.
I have an executable in another drive, let's say at D:\Folder\MyProg.exe.
Opening command prompt, it starts in the directory C:\Users\User
I type the command: start D:\Folder\MyProg.exe or D:\Folder\MyProg.exe
The exe fails to open, with a pop-up: MyProg has encountered an error
In order to run start the .exe from command prompt, I have to cd to the other directory and then start the exe.
Opening command prompt, it starts in the directory C:\Users\User
I type the command: cd /d D:\Folder && start MyProg.exe
The exe successfully opens.
Is there a better way to, from C:, start an executable in another drive?
Reproducing
Windows 10 Pro, v1809 (I don't think the version really matters)
My real use case is industrial automation, but one can observe the same result with convert.exe (cnet download link)
As commented by #Mofi, I realized the answer is most likely this:
But some programs are not good coded. Such programs depend on files in directory of the program and do not use appropriate code to reference those files from within the program with program files path, but use instead a relative path
As he instructed in the next comment, start provides a /d parameter that lets you specify a startup directory. Thus, a concise command would be:
start "" /d D:\Folder MyProg.exe
Note: the "" is for the <Title> field. The .exe I am opening is a GUI application (not a console application), so it is not necessary in this case, I just included in case other viewers find this useful in their application.
I have a Windows machine with the current user in C:\Users\User.
I have an executable in another drive, let's say at D:\Folder\MyProg.exe.
Opening command prompt, it starts in the directory C:\Users\User I type the command: start D:\Folder\MyProg.exe The exe fails to open.
In order to run start the .exe from command prompt, I have to cd to the other directory and then start the exe.
Maybe not. Try:
PATH D:\Folder;%Path%
"D:\Folder\MyProg.exe"
In a Windows batch file, or in the Command Prompt, what's the difference between calling start mspaint, for example, and mspaint? They appear to do exactly the same thing.
Another example, where all 4 cases appear to do the same thing. Can you please help me understand what are the subtle differences, if any?
taskmgr
C:\Windows\System32\Taskmgr.exe
start taskmgr
start C:\Windows\System32\Taskmgr.exe
Follow-up: it looks like start opens a separate background command prompt to run the program you write after it (source: https://technet.microsoft.com/en-us/library/cc770297(v=ws.11).aspx). Is this the same as Linux's myApp & format--where you have the & suffix?
Starting a Program
See start /? and call /? for help on all three ways.
Specify a program name
c:\windows\notepad.exe
In a batch file the batch will wait for the program to exit. When
typed the command prompt does not wait for graphical
programs to exit.
If the program is a batch file control is transferred and the rest of the calling batch file is not executed.
Use Start command
start "" c:\windows\notepad.exe
Start starts a program and does not wait. Console programs start in a new window. Using the /b switch forces console programs into the same window, which negates the main purpose of Start.
Start uses the Windows graphical shell - same as typing in WinKey + R (Run dialog). Try
start shell:cache
Also note the first set of quotes, if any, MUST be the window title.
Use Call command
Call is used to start batch files and wait for them to exit and continue the current batch file.
With Reference to Start and just typing a program name.
Help Windows Find Programs and Documents
Programs and documents can be added to the registry so typing their name without their path in the Start - Run dialog box or shortcut enables Windows to find them.
REGEDIT4
;The bolded name below is the name of the document or program, <filename>.<file extension>
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\IE.txt]
;The # means the path to the file is assigned to the default value for the key.
;The whole path in enclosed in a quotation mark ".
#="\"C:\\Program Files\\Internet Explorer\\IE.txt\""
;Optional Parameters. The semicolon means don't process the line. Remove it if you want to put it in the registry
;Informs the shell that the program accepts URLs.
;"useURL"="1"
;Sets the path that a program will use as its' default directory. This is commented out.
;"Path"="C:\\Program Files\\Microsoft Office\\Office\\"
For a technical discussion.
CMD preprocesses commands and finds the file then calls CreateProcess. Start - Run dialog or the Start command uses ShellExecuteEx which eventually calls CreateProcess.
This is CreateProcess rules - note CMD provides full paths to CreateProcess. https://msdn.microsoft.com/en-us/library/ms682425
1.The directory from which the application loaded.
2.The current directory for the parent process.
3.The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
5.The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6.The directories that are listed in the PATH environment variable. Note that this function does not search the per-application path specified by the App Paths registry key. To include this per-application path in the search sequence, use the ShellExecute function.
ShellExecuteEx is here https://msdn.microsoft.com/en-us/library/bb759784(v=vs.85).aspx
CMD preprocessing is available on my Skydrive - originally from MS web site but no more. See Windows NT Command Shell Ch 2 https://1drv.ms/f/s!AvqkaKIXzvDieQFjUcKneSZhDjw
you need to call start application when you want the application to launch and return immediately to the command shell for further commands.
(on Linux, closest equivalent of start is the & suffix)
Some commands have the ability to do that without start prefix. That's what you're experiencing.
On the other hand, if you want an application returning immediately to "block" the shell, prefix by cmd /c
Try cmd /c taskmgr for instance, you'll see it blocks the command window until you quit it.
About the question about taskmgr, the 3 possibilities amount to the same result:
taskmgr is in system path: with or without full path the system finds it
taskmgr returns to the command window immediately. In that case, start is redundant.
I have an application named DriveMaster which I want to run from command line with different arguments. The application is residing in:
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe\"
Now in Windows - Run, if I open command prompt and want to give a command like:
DriveMaster /s:Scriptname.srt
This should be able to launch DriveMaster with that particular script.
How can I do this? What should I need to add in the Environment variables so that I can run the application from command prompt?
In Windows 7:
In the menu Start click Computer
In the context menu, select System Properties
Select Advanced System Settings -> tab Advanced
Select Environment Variables Menu System Variables to find the PATH variable and click it.
In the editing window, change the PATH, adding value: ; C:\Program Files (x86)\ULINK DM2012 PRO NET\v970
Open Run and type: DriveMaster /s:Scriptname.srt
That's all.
When you're in the command prompt the working directory is given in the prompt:
C:\Users>
Here, I'm in the folder C:\Users. If I want to run a program or a script in the folder I'm currently in, I can use its name alone (e.g. DriveMaster). If the program is outside my working directory, I can't call it like that because there could be many DriveMasters in different folders throughout my computer. I can either change my directory to be the one that has this program, or I can specify where in the filesystem it's located.
Changing the directory and running:
C:\Users> cd "C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\"
C:\Program Files (x86)\ULINK DM2012 PRO NET\v970> DriveMaster
Specifying the full path:
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster"
(I need to use quotes here because the folder names have spaces and my command prompt may not know if it's part of the folder name or the beginning of another command or argument.)
On the same line I call the program, I can choose a number of arguments (also called options, switches, flags) to change the way to program behaves. If my program accepts another file and wants it in the form /s: and-then-the-filename, that file also needs to be in my working directory. If it lives somewhere else, I can use the full specification, like I've done above.
Environment variables are a little more complicated of a topic, but there is one we might be interested in here. The Path environment variable is a list of folders that the command prompt will look in when you try to use names of files that aren't in your working directory. If I know I'm going to be using this program frequently and like where it is, I can add its folder to my Path so that I can access it with just DriveMaster in the future:
set PATH=%PATH%;C:\Program Files (x86)\ULINK DM2012 PRO NET\v970
(If I mistype that command, though, I could break other things in a way that would be hard to fix.)
In a file name drivemaster.bat whch would be located at some point in the path,
#echo off
setlocal
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe" /s:Scriptname.srt
where Scriptname.srt would need to be quoted and supplied with a full pathname if it's not in the current directory.
Oh you want to type DriveMaster /s:Scriptname.srt
Then use
"C:\Program Files (x86)\ULINK DM2012 PRO NET\v970\DriveMaster.exe" %1
in that script in place of the original "c:..." line.
edit : removed stray terminal backslash from ...exe
I am a beginner in VBScript. I googled it & got to know that we can run VBScript from command line by executing below command:
For Example my vbscript name is Converter.vbs & it's present in folder D:\VBS.
I can run it through following methods:
CScript "D:\VBS\Converter.vbs"
OR
WScript "D:\VBS\Converter.vbs"
Now I would like to execute above VBScript without Cscript or Wscript command by simply typing the name of VBscript name i.e. Converter.
I DON'T WANT TO SPECIFY THE FULL PATH OF VBSCRIPT EVERYTIME.
Can anyone please guide me on how to do that ?
I'll break this down in to several distinct parts, as each part can be done individually. (I see the similar answer, but I'm going to give a more detailed explanation here..)
First part, in order to avoid typing "CScript" (or "WScript"), you need to tell Windows how to launch a * .vbs script file. In My Windows 8 (I cannot be sure all these commands work exactly as shown here in older Windows, but the process is the same, even if you have to change the commands slightly), launch a console window (aka "command prompt", or aka [incorrectly] "dos prompt") and type "assoc .vbs". That should result in a response such as:
C:\Windows\System32>assoc .vbs
.vbs=VBSFile
Using that, you then type "ftype VBSFile", which should result in a response of:
C:\Windows\System32>ftype VBSFile
vbsfile="%SystemRoot%\System32\WScript.exe" "%1" %*
-OR-
C:\Windows\System32>ftype VBSFile
vbsfile="%SystemRoot%\System32\CScript.exe" "%1" %*
If these two are already defined as above, your Windows' is already set up to know how to launch a * .vbs file. (BTW, WScript and CScript are the same program, using different names. WScript launches the script as if it were a GUI program, and CScript launches it as if it were a command line program. See other sites and/or documentation for these details and caveats.)
If either of the commands did not respond as above (or similar responses, if the file type reported by assoc and/or the command executed as reported by ftype have different names or locations), you can enter them yourself:
C:\Windows\System32>assoc .vbs=VBSFile
-and/or-
C:\Windows\System32>ftype vbsfile="%SystemRoot%\System32\WScript.exe" "%1" %*
You can also type "help assoc" or "help ftype" for additional information on these commands, which are often handy when you want to automatically run certain programs by simply typing a filename with a specific extension. (Be careful though, as some file extensions are specially set up by Windows or programs you may have installed so they operate correctly. Always check the currently assigned values reported by assoc/ftype and save them in a text file somewhere in case you have to restore them.)
Second part, avoiding typing the file extension when typing the command from the console window.. Understanding how Windows (and the CMD.EXE program) finds commands you type is useful for this (and the next) part. When you type a command, let's use "querty" as an example command, the system will first try to find the command in it's internal list of commands (via settings in the Windows' registry for the system itself, or programmed in in the case of CMD.EXE). Since there is no such command, it will then try to find the command in the current %PATH% environment variable. In older versions of DOS/Windows, CMD.EXE (and/or COMMAND.COM) would automatically add the file extensions ".bat", ".exe", ".com" and possibly ".cmd" to the command name you typed, unless you explicitly typed an extension (such as "querty.bat" to avoid running "querty.exe" by mistake). In more modern Windows, it will try the extensions listed in the %PATHEXT% environment variable. So all you have to do is add .vbs to %PATHEXT%. For example, here's my %PATHEXT%:
C:\Windows\System32>set pathext
PATHEXT=.PLX;.PLW;.PL;.BAT;.CMD;.VBS;.COM;.EXE;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY
Notice that the extensions MUST include the ".", are separated by ";", and that .VBS is listed AFTER .CMD, but BEFORE .COM. This means that if the command processor (CMD.EXE) finds more than one match, it'll use the first one listed. That is, if I have query.cmd, querty.vbs and querty.com, it'll use querty.cmd.
Now, if you want to do this all the time without having to keep setting %PATHEXT%, you'll have to modify the system environment. Typing it in a console window only changes it for that console window session. I'll leave this process as an exercise for the reader. :-P
Third part, getting the script to run without always typing the full path. This part, in relation to the second part, has been around since the days of DOS. Simply make sure the file is in one of the directories (folders, for you Windows' folk!) listed in the %PATH% environment variable. My suggestion is to make your own directory to store various files and programs you create or use often from the console window/command prompt (that is, don't worry about doing this for programs you run from the start menu or any other method.. only the console window. Don't mess with programs that are installed by Windows or an automated installer unless you know what you're doing).
Personally, I always create a "C:\sys\bat" directory for batch files, a "C:\sys\bin" directory for * .exe and * .com files (for example, if you download something like "md5sum", a MD5 checksum utility), a "C:\sys\wsh" directory for VBScripts (and JScripts, named "wsh" because both are executed using the "Windows Scripting Host", or "wsh" program), and so on. I then add these to my system %PATH% variable (Control Panel -> Advanced System Settings -> Advanced tab -> Environment Variables button), so Windows can always find them when I type them.
Combining all three parts will result in configuring your Windows system so that anywhere you can type in a command-line command, you can launch your VBScript by just typing it's base file name. You can do the same for just about any file type/extension; As you probably saw in my %PATHEXT% output, my system is set up to run Perl scripts (.PLX;.PLW;.PL) and Python (.PY) scripts as well. (I also put "C:\sys\bat;C:\sys\scripts;C:\sys\wsh;C:\sys\bin" at the front of my %PATH%, and put various batch files, script files, et cetera, in these directories, so Windows can always find them. This is also handy if you want to "override" some commands: Putting the * .bat files first in the path makes the system find them before the * .exe files, for example, and then the * .bat file can launch the actual program by giving the full path to the actual *. exe file. Check out the various sites on "batch file programming" for details and other examples of the power of the command line.. It isn't dead yet!)
One final note: DO check out some of the other sites for various warnings and caveats. This question posed a script named "converter.vbs", which is dangerously close to the command "convert.exe", which is a Windows program to convert your hard drive from a FAT file system to a NTFS file system.. Something that can clobber your hard drive if you make a typing mistake!
On the other hand, using the above techniques you can insulate yourself from such mistakes, too. Using CONVERT.EXE as an example.. Rename it to something like "REAL_CONVERT.EXE", then create a file like "C:\sys\bat\convert.bat" which contains:
#ECHO OFF
ECHO !DANGER! !DANGER! !DANGER! !DANGER, WILL ROBINSON!
ECHO This command will convert your hard drive to NTFS! DO YOU REALLY WANT TO DO THIS?!
ECHO PRESS CONTROL-C TO ABORT, otherwise..
REM "PAUSE" will pause the batch file with the message "Press any key to continue...",
REM and also allow the user to press CONTROL-C which will prompt the user to abort or
REM continue running the batch file.
PAUSE
ECHO Okay, if you're really determined to do this, type this command:
ECHO. %SystemRoot%\SYSTEM32\REAL_CONVERT.EXE
ECHO to run the real CONVERT.EXE program. Have a nice day!
You can also use CHOICE.EXE in modern Windows to make the user type "y" or "n" if they really want to continue, and so on.. Again, the power of batch (and scripting) files!
Here's some links to some good resources on how to use all this power:
http://ss64.com/
http://www.computerhope.com/batch.htm
http://commandwindows.com/batch.htm
http://www.robvanderwoude.com/batchfiles.php
Most of these sites are geared towards batch files, but most of the information in them applies to running any kind of batch (* .bat) file, command (* .cmd) file, and scripting (* .vbs, * .js, * .pl, * .py, and so on) files.
When entering the script's full file spec or its filename on the command line, the shell will use information accessibly by
assoc | grep -i vbs
.vbs=VBSFile
ftype | grep -i vbs
VBSFile=%SystemRoot%\System32\CScript.exe "%1" %*
to decide which program to run for the script. In my case it's cscript.exe, in yours it will be wscript.exe - that explains why your WScript.Echos result in MsgBoxes.
As
cscript /?
Usage: CScript scriptname.extension [option...] [arguments...]
Options:
//B Batch mode: Suppresses script errors and prompts from displaying
//D Enable Active Debugging
//E:engine Use engine for executing script
//H:CScript Changes the default script host to CScript.exe
//H:WScript Changes the default script host to WScript.exe (default)
//I Interactive mode (default, opposite of //B)
//Job:xxxx Execute a WSF job
//Logo Display logo (default)
//Nologo Prevent logo display: No banner will be shown at execution time
//S Save current command line options for this user
//T:nn Time out in seconds: Maximum time a script is permitted to run
//X Execute script in debugger
//U Use Unicode for redirected I/O from the console
shows, you can use //E and //S to permanently switch your default host to cscript.exe.
If you are so lazy that you don't even want to type the extension, make sure that the PATHEXT environment variable
set | grep -i vbs
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyw;.tcl;.PSC1
contains .VBS and there is no Converter.cmd (that converts your harddisk into a washing machine) in your path.
Update wrt comment:
If you 'don't want to specify the full path of my vbscript everytime' you may:
put your CONVERTER.VBS in a folder that is included in the PATH environment variable; the shell will then search all pathes - if necessary taking the PATHEXT and the ftype/assoc info into account - for a matching 'executable'.
put a CONVERTER.BAT/.CMD into a path directory that contains a line like cscript p:\ath\to\CONVERTER.VBS
In both cases I would type out the extension to avoid (nasty) surprises.
I am wondering why you cannot put this in a batch file. Example:
cd D:\VBS\
WSCript Converter.vbs
Put the above code in a text file and save the text file with .bat extension. Now you have to simply run this .bat file.
Why don't you just stash the vbscript in a batch/vbscript file hybrid. Name the batch hybrid Converter.bat and you can execute it directly as Converter from the cmd line. Sure you can default ALL scripts to run from Cscript or Wscript, but if you want to execute your vbs as a windows script rather than a console script, this could cause some confusion later on. So just set your code to a batch file and run it directly.
Check the answer -> Here
And here is an example:
Converter.bat
::' VBS/Batch Hybrid
::' --- Batch portion ---------
rem^ &#echo off
rem^ &call :'sub
rem^ &exit /b
:'sub
rem^ &echo begin batch
rem^ &cscript //nologo //e:vbscript "%~f0"
rem^ &echo end batch
rem^ &exit /b
'----- VBS portion -----
Dim tester
tester = "Convert data here"
Msgbox tester
You may follow the following steps:
Open your CMD(Command Prompt)
Type 'D:' and hit Enter. Example: C:\Users\[Your User Name]>D:
Type 'CD VBS' and hit Enter. Example: D:>CD VBS
Type 'Converter.vbs' or 'start Converter.vbs' and hit Enter. Example: D:\VBS>Converter.vbs Or D:\VBS>start Converter.vbs
I am using Windows 7
How can i run an input file (text file of commands) in an exe progam in CMD please.
Using other questions on the site, i have tried:
CMD /c ""C:/Program Files/Mplus/Mpluswin.exe" "C:/Users/jj/Desktop/mplus/test_mplus.inp""
which opens the input file in the program but does not run it
and this, which opens the program, but not the script
CMD /c "C:/Program Files/Mplus/Mpluswin.exe" < "C:/Users/jj/Desktop/mplus/test_mplus.inp"
Does this depend on the exe program?
Edit:
At present, the first command above launches the exe program and opens the text file within it (this is a file of program specific commands that will read in data, run calculations and output automatically). I can then run the commands in the exe program that has been opened (by selecting run in a menu) . But, I would like to pass the file to the exe program and it to be run automatically, ideally in the background. I am not sure of the correct terminology to use, so sorry if my description is unclear.
I've just noticed that you enclosed the entire term in an extra set of double quotes, and used linux forward slashes - try this batch file and also see if there is any error message on the console.
#echo off
cd /d "%userprofile%\Desktop\mplus"
"C:\Program Files\Mplus\Mpluswin.exe" "test_mplus.inp"
echo mplus was launched
pause