Related
A way to run multiple programs in a bat file.
Objective
Distribute a software with GDAL as a dependency.
To do that I have downloaded gdal binaries from GIS Internals. The downloaded data has a .bat file to set environment variables. It uses set command to set the environment variables.
As per my limited knowledge in windows bash scripting, I understand that the environment variables set by set are limited to current command prompt itself and are reset when a new command prompt is launched.
Also, is it true that a calling a batch file from a batch file launches new command prompt which when closes doesn't affect the next command called in the parent script.
There is another issue here - will the environment variables affect the process created (such as calling gdal_translate) by a Java program? If it doesn't, then there is no point in setting local environment variable.
Final Requirement:
How to use the environment variables set in another batch file (called from a batch file) in the next line of the parent batch file, without using setx?
If you use the CALL command to run the batch file as specified in the accepted answer on the question you linked to, then the environment variables will pass up to the parent batch file.
There are three times where this is not true:
When using SETX neither the parent nor child batch file will get the environment variables.
When using SETLOCAL and ENDLOCAL inside the child batch file the parent batch file will not get the environment variables.
When running the child batch file using start or cmd.exe /c.
So long as you run your Java application in the same environment (i.e. the same batch file), it will pick up the same environment variables. You can verify this with an application like Process Explorer.
Running set _kjhgkjshdgkjhdfg=TEST before running a .jar file resulted in the screenshot below using any of:
javaw -jar jarfile.jar
cmd /c javaw -jar jarfile.jar
start cmd /c javaw -jar jarfile.jar
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
I have a very simple Windows .BAT file:
set PATH=c:\xxx;%PATH%
call foo.pl
set VAR=true
I thought "call" will start a new batch process, without affecting the current one. However, the batch file exited immediately after the foo.pl finished executing. The set VAR=true has never been called.
Is there a way to fix it?
foo.pl is not a batch file, it is a Perl script.
So you need to use
path c:\xxx;%PATH%
"Path to\Folder With\perl.exe" "foo.pl"
rem Additional batch code executed after Perl script execution finished.
In other words you have to run the console application perl.exe best with full path, or with just perl.exe if program files folder of Perl is not the same on all computers on which this batch file is used and hopefully PATH contains also the directory containing perl.exe.
If you specify on a command line or in a batch file just foo.pl, Windows looks in Windows registry which application is associated with .pl for action Open. If there is such a file association, Windows runs this application in a separate process like when using command start.
So using call foo.pl is like using start foo.pl.
PATH is not only an environment variable, but also an interal command written for changing the value of environment variable PATH at any time within a batch file. This is the reason why I removed set from first line. It is better to use internal command path for modifying environment variable PATH.
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
As I understand it, .bat is the old 16-bit naming convention, and .cmd is for 32-bit Windows, i.e., starting with NT. But I continue to see .bat files everywhere, and they seem to work exactly the same using either suffix. Assuming that my code will never need to run on anything older than NT, does it really matter which way I name my batch files, or is there some gotcha awaiting me by using the wrong suffix?
From this news group posting by Mark Zbikowski himself:
The differences between .CMD and .BAT as far as CMD.EXE is concerned
are: With extensions enabled, PATH/APPEND/PROMPT/SET/ASSOC in .CMD
files will set ERRORLEVEL regardless of error. .BAT sets ERRORLEVEL
only on errors.
In other words, if ERRORLEVEL is set to non-0 and then you run one of those commands, the resulting ERRORLEVEL will be:
left alone at its non-0 value in a .bat file
reset to 0 in a .cmd file.
Here is a compilation of verified information from the various answers and cited references in this thread:
command.com is the 16-bit command processor introduced in MS-DOS and was also used in the Win9x series of operating systems.
cmd.exe is the 32-bit command processor in Windows NT (64-bit Windows OSes also have a 64-bit version). cmd.exe was never part of Windows 9x. It originated in OS/2 version 1.0, and the OS/2 version of cmd began 16-bit (but was nonetheless a fully fledged protected mode program with commands like start). Windows NT inherited cmd from OS/2, but Windows NT's Win32 version started off 32-bit. Although OS/2 went 32-bit in 1992, its cmd remained a 16-bit OS/2 1.x program.
The ComSpec env variable defines which program is launched by .bat and .cmd scripts. (Starting with WinNT this defaults to cmd.exe.)
cmd.exe is backward compatible with command.com.
A script that is designed for cmd.exe can be named .cmd to prevent accidental execution on Windows 9x. This filename extension also dates back to OS/2 version 1.0 and 1987.
Here is a list of cmd.exe features that are not supported by command.com:
Long filenames (exceeding the 8.3 format)
Command history
Tab completion
Escape character: ^ (Use for: \ & | > < ^)
Directory stack: PUSHD/POPD
Integer arithmetic: SET /A i+=1
Search/Replace/Substring: SET %varname:expression%
Command substitution: FOR /F (existed before, has been enhanced)
Functions: CALL :label
Order of Execution:
If both .bat and .cmd versions of a script (test.bat, test.cmd) are in the same folder and you run the script without the extension (test), by default the .bat version of the script will run, even on 64-bit Windows 7. The order of execution is controlled by the PATHEXT environment variable. See Order in which Command Prompt executes files for more details.
References:
cmd.exe
command.com
wikipedia: Comparison of command shells
These answers are a bit too long and focused on interactive use. The important differences for scripting are:
.cmd prevents inadvertent execution on non-NT systems.
.cmd enables built-in commands to change Errorlevel to 0 on success.
Not that exciting, eh?
There used to be a number of additional features enabled in .cmd files, called Command Extensions. However, they are now enabled by default for both .bat and .cmd files under Windows 2000 and later.
Bottom line: in 2012 and beyond, I recommend using .cmd exclusively.
No - it doesn't matter in the slightest. On NT the .bat and .cmd extension both cause the cmd.exe processor to process the file in exactly the same way.
Additional interesting information about command.com vs. cmd.exe on WinNT-class systems from MS TechNet (http://technet.microsoft.com/en-us/library/cc723564.aspx):
This behavior reveals a quite subtle
feature of Windows NT that is very
important. The 16-bit MS-DOS shell
(COMMAND.COM) that ships with Windows
NT is specially designed for Windows
NT. When a command is entered for
execution by this shell, it does not
actually execute it. Instead, it
packages the command text and sends it
to a 32-bit CMD.EXE command shell for
execution. Because all commands are
actually executed by CMD.EXE (the
Windows NT command shell), the 16-bit
shell inherits all the features and
facilities of the full Windows NT
shell.
RE: Apparently when command.com is invoked is a bit of a complex mystery;
Several months ago, during the course of a project, we had to figure out why some programs that we wanted to run under CMD.EXE were, in fact, running under COMMAND.COM. The "program" in question was a very old .BAT file, that still runs daily.
We discovered that the reason the batch file ran under COMMAND.COM is that it was being started from a .PIF file (also ancient). Since the special memory configuration settings available only through a PIF have become irrelevant, we replaced it with a conventional desktop shortcut.
The same batch file, launched from the shortcut, runs in CMD.EXE. When you think about it, this makes sense. The reason that it took us so long to figure it out was partially due to the fact that we had forgotten that its item in the startup group was a PIF, because it had been in production since 1998.
Still, on Windows 7, BAT files have also this difference : If you ever create files TEST.BAT and TEST.CMD in the same directory, and you run TEST in that directory, it'll run the BAT file.
C:\>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
C:\Temp>echo echo bat > test.bat
C:\Temp>echo echo cmd > test.cmd
C:\Temp>test
C:\Temp>echo bat
bat
C:\Temp>
Since the original post was regarding the consequences of using the .bat or .cmd suffix, not necessarily the commands inside the file...
One other difference between .bat and .cmd is that if two files exist with the same file name and both those extensions, then:
entering filename or filename.bat at the command line will run the .bat file
to run the .cmd file, you have to enter filename.cmd
everything working in a batch should work in a cmd; cmd provides some extensions for controlling the environment.
also, cmd is executed by in new cmd interpreter and thus should be faster (not noticeable on short files) and stabler as bat runs under the NTVDM emulated 16bit environment
.cmd and .bat file execution is different because in a .cmd errorlevel variable it can change on a command that is affected by command extensions. That's about it really.
I believe if you change the value of the ComSpec environment variable to %SystemRoot%system32\cmd.exe(CMD) then it doesn't matter if the file extension is .BAT or .CMD. I'm not sure, but this may even be the default for WinXP and above.
The extension makes no difference.
There are slight differences between COMMAND.COM handling the file vs CMD.EXE.
a difference:
.cmd files are loaded into memory before being executed. .bat files execute a line, read the next line, execute that line...
you can come across this when you execute a script file and then edit it before it's done executing. bat files will be messed up by this, but cmd files won't.