I don't see any difference when executing each of those two lines of batch file code
Wscript Test.vbs
Wscript //Nologo Test.vbs
Where is the logo suposed to be located?
Though your question is not clear, I shall tell you the concept of logo/nologo
//logo
Displays a logo when the script runs under CScript (this is the default setting for WSH). The logo, which appears prior to any of the output from the script, looks like this:
Microsoft (R) Windows Script Host Version 5.6Copyright (C) Microsoft
Corporation 1996-2000. All rights reserved.
//nologo
Prevents display of the logo at run time (by default, the logo is displayed).
The //nologo option is often used for scripts whose output is redirected to a text file. Suppressing the logo ensures that this information does not appear within the text file. This makes it easier to write scripts that parse the information found in the text file or that import the contents of the file to a database, because these scripts do not have to account for the logo.
//S
Saves the Timeout and Logo options for this user.
For example, this command ensures that the logo will be suppressed anytime a script runs under CScript:
cscript //nologo //S
You can also modify these settings by right-clicking a script file and then clicking Properties.
Hope you got some benefit from this answer....
Related
When I use slmgr /skms <URL> | cmd command in PowerShell it shows me a pop up that I must press the ok button after that I run slmgr /ato | cmd and again shows me another pop up that I press the ok button.
I don't want to press the ok button manually, can anybody help me if there is a solution for it, please?
I just disabled the uac in windows, but it does not help me.
What you are looking for is cscript. By just executing a vbs script file, output gets sent to dialog boxes, which need your interaction.
Using cscript, the desired output gets printed to your current stdout:
cscript C:\Windows\System32\slmgr.vbs /ato
That doesn't have anything to do with UAC and you might consider re-activating it.
But why is that?
slmgr is not a command nor is it an executable in windows. It's a script file written in VBScript. VBScript is a kind-of scripting version of VB, So it's good for your peace of mind not to deal with it too much.
If you type in slmgr /skms, what windows does is looking for a file named slmgr in its search paths (%PATH%), finding C:\Windows\System32\slmgr.vbs and deciding that, as its a .vbs file, executing wscript.exe with the file path and your arguments as parameter is the right thing to do.
WScript is the default interpreter for vbs files and just interprets the file and executes its code. On the other hand, there is cscript for console scripts.
If the author of the .vbs file decides to write a message to the user of their script, they usually use a statement like
Wscript.Echo "Hello, World!"
And thats where your confusion starts:
Executing this script in cscript means that Hello, World! is written to the console. (That's what you want to do)
Executing the same script using wscript renders a message box with a OK button. You can easily reproduce it yourself by creating a vbs file with the above statement.
The difference between cscript and wscript is also discussed in this question:
Difference between wscript and cscript
In a batch file I can get the width of the console window using one of the examples here:
Windows console width in environment variable
#echo off
for /F "usebackq tokens=2* delims=: " %%W in (`mode con ^| findstr Columns`) do set CONSOLE_WIDTH=%%W
echo Console is %CONSOLE_WIDTH% characters wide
Similarly, I would like to know how to get the width of the parent shell's console when I run a VBscript from a Command Prompt. If I try running the above batch file from VBscript using:
CreateObject("WScript.Shell").Run "cmd /k FindWidth.bat"
A new console opens, and the width given by FindWidth.bat is for the new console window, not the console of the parent shell.
Using VBscript I can find the process ID of the parent shell using the following method: In a vbscript, how can i get the process id of the cmd.exe in which the vb script is running. Is there a way to do something similar to find its console column width? Maybe another method can be used since the process ID is known?
EDIT UPDATES:
I thank everyone for the comments. I'll try to add some more information of what I'm trying to accomplish. I have a kind of work around already but I was hoping for a slightly better solution.
The VBscript is run from a Command Prompt directly. Unfortunately, the VBscript is most likely run from wscript.exe because that is the default on normal Windows installations. But I still want to output error messages and other messages to the console and not to a popup window.
If I could guarantee it was run with cscript, there would be no problems. Restarting the VBscript with cscript starts a new process so any messages from the newly run csript VBscript go to a new console and not the original console.
I have a solution which works but it is clumsy because it uses a batch file wrapper with the same name as the .vbs but with a .bat extension instead of .vbs extension. All the batch script does is run the VBscript using cscript. It is mentioned in this topic: In vbscript, how do I run a batch file or command, with the environment of the current cmd prompt window?
I was hoping to find a way to get rid of the batch file wrapper but now I don't think it is possible.
I was trying another workaround which allows WScript to be used. Since the process ID of the console window can be obtained, a message can be sent to the original console window by first guaranteeing it is activated with:
objShell.AppActivate(ProcessID)
Then the script can immediately send a message to the original console with:
objShell.SendKeys ":: " & WindowMessage & "{enter}"
The trick is using "::" to make the message a comment that doesn't do anything. This works okay. One small problem is that it makes the console window use the comment for the last command buffer so if the user presses the up arrow or F3 etc, the comment is shown like it was a command they typed themselves. That is annoying but since it is just a comment, no errors are produced and it isn't much of a problem.
The part that is annoying is that the message appears on the same line as a normal command and doesn't look like a proper cscript sent message. The reason I wanted the width of the console is to format the message by buffering it with the proper number of spaces so that it looks identical to a message that would have been sent from cscript. Then it would look like real stdout output except for the ":: " at the start of the message.
The script could just read the default setting for the command prompt but that will not format it correctly in a lot of cases.
If I could find a way to go to a new line with SendKeys and send the message before the PROMPT appears, that would do the same thing. Is there a character that could be sent which would start a new line before the PROMPT appears??
Is there a way of using VBscript to inject a text message into the stdout of a specific console window. Being that the process ID is known of the console that should get the stdout, is it possible for the wscript VBscript to run another batch script or another program silently which could use the Process ID to inject a message into the stdout of the original console window.
Ultimately, all I wanted was to have the VBscript file be run directly in a Command Prompt that can output messages to that same console. But to do that properly seems to require the user type "cscript scriptname.vbs arguments" instead of just "scriptname arguments" which is how it should be possible but apparently isn't! Using a batch file wrapper is another option that kind of tricks the user into running a different batch file instead of the VBscript file directly. I guess I would need to redo the script in a real computer language instead of a scripting language to make it work properly. I really don't understand why this is so difficult to accomplish with VBscript when it seems like it should be trivial.
It is a bit annoying that Windows sets VBscript to use WScript by default when WScript doesn't allow any console output at all. But CSCript can do both Windows popups and console output. Why even have WScript vs CScript distinction at all when it seems like everything can be done with CScript alone?
I am trying to automate a VBScript by using Windows Task Scheduler. However, I tried to use cscript.exe + "C:\...\script.vbs" but it didn't run. I also tried to directly run the same command in CMD (cscript.exe "C:\...\script.vbs") and it worked.
What might be the problem?
EDIT :
I just tried to switch the setting to "Run only when user is logged on" from "Run whether user is logged on or not" and it worked. I am wondering if there is a way to make my task scheduled run even when the user is logged off.
After hours of research, one of Blake Morrison (from Microsoft)'s blogs came up; it mentioned that
If running a .vbs / .ps1 script, try launching it from a .cmd / .bat script
see Help! My Scheduled Task does not run…
That blog also explains a lot of rules/tips when using Task Scheduler.
So please create a .cmd/.bat file that calls for your VBScript. For example: cscript.exe YourScript.vbs would be in your .cmd/.bat script.
Write a batch file like this:
echo "Started!" > c:\foldergoeshere\log.txt
cscript.exe "C:\...\script.vbs" > c:\foldergoeshere\log.txt
echo "Stopped!" > c:\foldergoeshere\log.txt
Then schedule the batch file instead of the vbs. That will allow you to see what is happening that is preventing it from running. Any error that you would have seen executing in the console (CMD), will be instead output to that log file between "Started!" and "Stopped!"
What's the hassle all about? I don't use .cmd/.bat and script works! (Windows7 here)
My VBS script (as a scheduled task) runs well on any scenario of these 4:
cscript and option "Run only when user is logged on"
cscript and option "Run whether user is logged on or not"
wscript and option "Run only when user is logged on"
wscript and option "Run whether user is logged on or not"
It's only that on the 1st scenario I encounter the black command window flashing on my screen.
Action settings:
or
My script, which simply creates a file:
Set objFSO = CreateObject("Scripting.FileSystemObject")
filename = "C:\Temp\" & Hour(Time) & Minute(Time) & Second(Time)
Set objFile = objFSO.CreateTextFile(filename)
Greg answered this https://superuser.com/a/816073
Basically you need to create 2 folders:
You have to create a folder (or two on a 64bit-windows):
(32Bit, always) C:\Windows\System32\config\systemprofile\Desktop
(64Bit) C:\Windows\SysWOW64\config\systemprofile\Desktop
Fixed the issue for me (and I could point to the .vbs file, not bat needed).
The .vbs file is running invisibly, which is a consequence of running it with the 'logged on or not' option.
You will not be allowed to interfere with a user using the computer, which means you will be able to help yourself, but not others.
Please read the following text from the Task Scheduler Help menu:
Task Security Context
You can specify that a task should run even if the account under which the task is scheduled to run is not logged on when the task is triggered.
To do this, select the radio button labeled Run whether user is logged on or not.
If this radio button is selected, tasks will not run interactively.
To make a task run interactively, select the Run only when user is logged on radio button.
You can do this.
cmd as the Program.
/c start cscript //nologo "W:\Pathto with spaces\VBScript.vbs"
/c send the following to the cmd
start starts the next parameter
cscript //nologo "W:\Path with spaces\VBScript.vbs" self explanatory. Path wrapped in quotes to allow spaces in the filename.
Screenshot
Have experienced more than once that a VBScript running as planned task worked fine for months and years but suddenly would not work any more despite nothing was changed. Have tried to reactive the task using all the recipes given here and elsewhere, but no success. My workaround was to create a new planned task with all settings copied from the original one.
I tried this on Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
AKA Window 7, But in my case i first cd to the dir and then ran the .bat file to execute the .vbs file
Go to start menu
Search for run
Once it opens, Type "shell:startup" and press Enter
You'll be directed to the Start Up folder. In this folder you can put create a .bat file which you want to execute the .vbs file (You'll do this in a special way)
cd C:\the\path\were.vbs\file\located && wscript.exe start_app.vbs
What your doing is cd to the directory cd C:\the\path\were.vbs\file\located
And then run the .vbs file wscript.exe start_app.vbs
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've created a simple batch file that kicks off my *.msi installer within our company, creating a log file of the process, then displays the log file after the installer has completed.
installAndLog.bat:
msiexec.exe /i "\\FileServer2\setup.msi" /l*v "C:\setupLog.txt"
"C:\setupLog.txt"
It works, but there are two (2) glitches that annoy me:
The black console box shows in the background the whole time the installer is running and the log file is being displayed. Q1: How do I hide that?
and
The console box will not close until the log file is no longer being viewed (i.e. notepad.exe is closed). Q2: Can I call the text file in a new process and simply exit?
I was a DOS lover back in the day, but that was too many years ago.
I don't think you can hide the console window when running a batch file. However you can use vbscript instead which will by default not create a console window.
Take the below and put it in a file with a .vbs extension:
Dim wshShell
Set wshShell = CreateObject("WScript.Shell")
wshShell.Run "msiexec.exe /i ""\\FileServer2\setup.msi"" /l*v ""C:\setupLog.txt""", 1, true
wshShell.Run "C:\setupLog.txt"
All the double double quotes are there because the entire command must be surrounded by "'s and doubling them escapes them. The the documentation for WshShell.Run for more info.
Q1 - AFAIK you can't really hide the console window.
Q2 - Use the start command. This will launch the specified program (notepad) outside of the shell. It will also prevent the shell from waiting until the application closes to continue processing the batch script.
You might be better off changing the batch script to launch the MSI installer using the start command and having the installer launch notepad to view the log file once installation is complete.
If you really want to get these batch windows away, you'll have to switch over to something else. One simple alternative could be one of the scripting languages supported by the windows scripting host.
Or you try HTA (HTML applications) see here and here.
Run the dos script as a different user by scheduled task or as a service.