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 came across a way to convert my .bat with dependencies on tool to an .exe file. However when I try using the script and run the .exe created, I always getting an error. Seems I modified the script incorrectly.
Anyone can help, please?
Here's the code with my modifications:
#ECHO OFF
ECHO Make EXE From BAT
ECHO Written by: Jason Faulkner
ECHO SysadminGeek.com
ECHO.
ECHO.
REM Usage:
MakeExeFromBat BatFileToConvert -bat MyProgram.bat
REM
REM Required Parameters:
BatFileToConvert -save MyProgram
REM Source batch file to use to produce the output Exe file.
REM
REM Optional Parameters:
IncludeFile -include Tool.exe
REM Additional files to include in the Exe file.
REM You can include external tools used by the batch file so they are available on the executing machine.
SETLOCAL
REM Configuration (no quotes needed):
SET PathTo7Zip=C:\Desktop\
REM ---- Do not modify anything below this line ----
SET OutputFile="%~n1.exe"
SET SourceFiles="%TEMP%\MakeEXE_files.txt"
SET Config="%TEMP%\MakeEXE_config.txt"
SET Source7ZFile="%Temp%\MakeEXE.7z"
REM Remove existing files
IF EXIST %OutputFile% DEL %OutputFile%
REM Build source archive
ECHO "%~dpnx1" > %SourceFiles%
:AddInclude
IF {%2}=={} GOTO EndInclude
ECHO "%~dpnx2" >> %SourceFiles%
SHIFT /2
GOTO AddInclude
:EndInclude
"%PathTo7Zip%\7za.exe" a %Source7ZFile% #%SourceFiles%
REM Build config file
ECHO ;!#Install#!UTF-8! > %Config%
ECHO RunProgram="%~nx1" >> %Config%
ECHO ;!#InstallEnd#! >> %Config%
REM Build EXE
COPY /B "%PathTo7Zip%\7zsd.sfx" + %Config% + %Source7ZFile% %OutputFile%
REM Clean up
IF EXIST %SourceFiles% DEL %SourceFiles%
IF EXIST %Config% DEL %Config%
IF EXIST %Source7ZFile% DEL %Source7ZFile%
ENDLOCAL
This doesn't really convert a bat file to an exe. It just creates a selfextracting archive (exe) which contains the bat file. On execution it extracts the file to a temporary folder and runs it from there. You can even extract the bat from the exe just by using 7zip/rar/winzip or any other archiver.
If you want to convert a bat to an exe for real you should use one of the tools from the web (like this one: http://www.f2ko.de/index.php?lang=en) or concider using a simple script language like AutoIt.
If you pick the second, you can simply execute your bat code with Run("put your bat code in here") and you can compile your script to a "real" exe file.
For an alternative approach, you can basically do the same thing as described in the accepted answer (making a 7z-SFX) with WinRAR. That way, you can also do it with a GUI, and I will try to add some more useful information.
Actually, you can also use the latter approach to generate portable applications and it also works with "converting" every runnable (or openable) file into an .exe.
If you need that "portability hack", you should unpack your .exe or .msi installer with Universal Extractor. Details can be found in this Article, Step 1 to 4. Newer Versions of 7zip or WinRAR also come with comparable features.
Now you add all needed files to the archive. In the easiest case, this is just your .bat script or whatever file you want to "convert" into an .exe applivation. (Step 5 here)
Steps 6 and 7 are just some Settings for the SFX-Archive, 8 is the interesting one, as you select what you actually want to run there. Input the name of your (.bat-)file.
Step 9 lets you select where to unpack to - you do this setting manually and programmatically in the MakeExeFromBat.bat-script.
After this process you created a Portable App in SFX archiever form, enjoy
The word "converting" was put into quotation marks, because running that .exe actually works like this:
The contents of the (SFX-)EXE file are extracted from the "archive part" to a directory as the specified temp directory.
( The config file generated by the script is read. )
The file, that was previously contained in the EXE file and then extracted, is now executed in a new window.
a) This file could besides a .bat be anything - as e.g. an image, a MP3 or a video
b) or also a Python Script (of course your OS needs to know how to deal with that file.
Once finished, the temp files are removed.
You can also derive some limitations from that. If you have a .bat that needs the content of the working directory, you will have a problem. (Say, a batch that renames all files in the current dir from 1 to n.) In some cases that can be dealt with by adding all needed files to the archive too. On Windows Vista and all newer OSes, you might encounter a message box after the script is run. After selecting ‘This program installed correctly’, the message box will not be displayed in the future for this file. Because the EXE file launches in a new window, the typical way of logging output (using the > char) will not work as expected. In order to log the output, you would need to handle this natively in your source script.
All references were already linked, but once again: Big credit goes to Jason Faulkner for providing the Article and 7zip-Approach, binbert for the WinRAR-SFX Solution (which is as hinted much more versatile -> portability) and some credit to creative8 for finding the two and the article comparing them.
Actually, I was develping another solution using AutoHotkey. In my case, I just want to be able to add my .bat to the windows start menu - but the options are not limited to that.
The script itself is just a oneliner and .AHK is easily converted to .exe (I used v1.1.33.09):
run % SubStr(A_ScriptName, 1, -4) ;// run also has the option to run your file minimized or hidden, see the source 2 below
Source 2
What it does is taking its own name, removing the .ahk or .exe respectively (the last 4 characters, hence -4) and running excactly that. Usage could not be easier: you have a runme.bat, so you rename the program I provide to runme.bat.exe. Say you want the .exe to open an image.png - guess what, rename it to image.png.exe. You get the gist - that's it. It dynamically checks its name to find what to run. In my opinion, this is not much less mighty than "unpacking the .bat and then run it", but (again imho) it is much more elegant.
Use it as you wish, I should probably start a public github page or so.
I currently have a Windows batch file that runs an .exe file that uses a text file. I am trying to have the Windows batch file run the .exe file multiple times. This, however, requires the use of the same text files to read from. The command prompt gives me the error that the ".txt could not be opened" (I assume from this that it is already open.)
I am trying to see if there is a way in a .bat file to system call to kill that specific text file. The suggestions I see online are to use 'taskkill notepad.exe', but that returns "invalid argument" because the program doesn't open Notepad to use the text file.
Any suggestions would be appreciated.
It sounds like your existing script fails because the first instance of the exe is still open when the second instance starts.
One thing worth trying (and this depends on the nature of the application you are invoking) is to start the executable using the START /WAIT /B ... command. This makes the command interpreter wait for the program to exit before it moves onto the next command, so as long as nothing else is locking the text files you should be OK to move onto the next command.
This is a line of code from a batch file I'm working on.
echo %systemroot% >> untitled.bat
It's job is to append the text %systemroot% to another batch file called untitled.bat.
When I open the untitled.bat file with notepad to view the code it reads C:\Windows.
This makes sense because that is my %systemroot% but my problem is that I want the code to be written to the untitled.bat file as %systemroot% not C:\Windows.
Does anyone know how (if at all) this is possible?
This line of code works for me:
echo %%systemroot%% >> untitled.bat
Initially I captured a file using batch file and it is open with Notepad. How do I code the batch file so that it will save with WordPad.
Batch File :
Remarks:This document is for Linksys for version v4.30.5, the auto sensing part.
"C:\Program Files (x86)\Wireless Guard\wget" "http://192.168.1.254/xslt#PAGE=C_2_0"
copy "xslt#PAGE=C_2_0" "xslt#PAGE=C_2_0.txt"
del "xslt#PAGE=C_2_0"
You don't really have to do anything to get it to save with WordPad as such. As previously commented batch files output to plain text so you can open it with WordPad if you wish.
You could do this in batch with:
write txtfile.txt
Or to permanently associate WordPad set it as your default txt program in Control Panel.
Hope this helps.