vbscript macros shortening lines of code - shell

so like in C++ where you can turn lines into one word (macro, yes?), is there a way to do this in vbscript?
e.g. instead of
Set shell = WScript.CreateObject("WScript.Shell")
Set sh = WScript.CreateObject("WScript.Shell").Exec("Firefox")
Can I shorten to something like
Set shell = MACRO.Exec("Firefox")
If it's just as simple as making a function to do it, can someone give in an example of how to do that whilst adding the ".Exec" to it?

You may shorten the code creating an auxiliary function:
Dim WshExec
Set WshExec = WshShell.Exec("notepad")
Function WshShell()
Set WshShell = CreateObject("WScript.Shell")
End Function

CreateObject("Wscript.Shell").exec("firefox")
Follow the dots. There is an implicit (unnamed) variable, that exists only for the lifetime of the line, holding a wscript.shell object. Then you call the exec method on that implicit variable.
Exec is the wrong command. You need Run.
Download help to see the difference http://download.microsoft.com/download/winscript56/Install/5.6/W982KMeXP/EN-US/scrdoc56en.exe.

Related

Get return code from an exe using VBScript is not working

I have an command line app that queries some Scheduled Tasks and returns 0 if ready and 1 if not.
I need to get that return code from a VBScript, but I am getting 0 always, even if the app returns 1. This is the code I have:
StrCommandLine = """C:\Program Files (x86)\App\TaskValidator\TaskValidator.exe"""
Set oshell = CreateObject("WScript.Shell")
iReturn = oShell.run(StrCommandLine,0,true)
wscript.echo iReturn
If I run the app from a CMD, it returns 1 if not ready. I think it is because I am getting the last error code from CMD itself.
Any help you can give me?
From Help http://download.microsoft.com/download/winscript56/Install/5.6/W982KMeXP/EN-US/scrdoc56en.exe
You are not setting an error code.
Quit Method (Windows Script Host)
Forces script execution to stop at any time.
object.Quit([intErrorCode])
object
WScript object.
intErrorCode
Optional. Integer value returned as the process's exit code. If you do not include the intErrorCode parameter, no value is returned.
Remarks
The Quit method can return an optional error code. If the Quit method

How to run multiple TCL scripts in same tclsh window?

Description
I work with VBScript
From VBScript I call my first TCL script "name1"
After the script "name1" is finished, I continue to work with VBScript
After several VBScript functions I call my second TCL script "name2" and this script is a child process of the script "name1". The script "name2" have to use all variables from the script "name1"
Current result
My scripts "name1" and "name2" are executing in the different tclsh windows
As a result, the "name2" is not familiar with the variables of the "name1"
Expected result
"name1" and "name2" are executed in the same tclsh window
Comment
I tried to use these commands but I don't know its syntax in the VBScript
Tcl_Create tclHandler,
TCL_Eval Status, tclHandler,
It would be nice to have an example how to use these commands in the VBScript, or any other
Thanks
VBScript:
#$language = "VBScript"
#$interface = "1.0"
Const ForReading = 1
Const ForWriting = 2
Const ForAppending = 8
crt.Screen.Synchronous = True
Sub Main
dim shell
set shell=createobject("wscript.shell")
shell.run "tclsh e:\RunTCL\name1.tcl"
crt.Sleep 10000 ' or any VBScript commands
shell.run "tclsh e:\RunTCL\name2.tcl"
End Sub
name1.tcl
package req SpirentTestCenter
set hProject [stc::create project]
set hTxPort [stc::create port -under $hProject -location //192.168.0.243/10/17 -useDefaultHost False]
name2.tcl
set hRxPort [stc::create port -under $hProject -location //192.168.0.243/10/25 -useDefaultHost False]
New code with tcl84.dll and its commands "TCL_Create tclHandler,":
#$language = "VBScript"
#$interface = "1.0"
Const ForReading = 1
Const ForWriting = 2
Const ForAppending = 8
crt.Screen.Synchronous = True
Sub Main
Dim wscriptTCL
tclHandler = 0
set wscriptTCL =CreateObject("C:\Tcl\bin\tcl84.dll")
TCL_Create tclHandler, wscriptTCL, 1
puts "Importing STC API"
TCL_Eval Status, tclHandler, "package req SpirentTestCenter"
puts "Creating API objects set"
TCL_Eval Status, tclHandler, "set hProject [stc::create project]"
puts "Connecting to STC ports"
TCL_Eval Status, tclHandler, "set hTxPort [stc::create port -under $hProject -location //10.110.10.243/8/9 -useDefaultHost False]"
src.Sleep 100000
TCL_Eval Status, tclHandler, "set hRxPort [stc::create port -under $hProject -location //10.110.10.243/8/10 -useDefaultHost False]"
As a result, I see this message: Error:ActiveX component can't create object 'c:\tcl\bin\tcl84.dll'
I can use 2 options:
Call the tcl file from my VB script
Call tcl commands from the VB script via dll
But nobody is working
Good news, it starts to work, however, I would prefer to execute separate TCL files by API
shell.run "tclsh"
crt.Sleep 10000
shell.AppActivate "tclsh"
shell.SendKeys("TCL command")
tcl84.dll is not something that provides a COM class. You cannot create a Tcl interpreter using the VBScript CreateObject call like this. VBScript does not have a mechanism to access exported functions directly from a DLL so you cannot run your Tcl code from VBScript except by executing a tclsh or wish process.
Each time you execute tclsh.exe scriptfile you are creating a new child process. It will run your script but when it exits the process is terminated and everything about it is lost unless you read the standard output or wrote information to a file to preserve it. So running a second script will of course have no knowledge of the first script.
One way to run two tcl scripts together is to create a script that uses the tcl source command to load both scripts into a single interpreter. Another method might be to read the output of the first script, parse out the values you need and pass these as command line arguments to the second. Or you could have the first script write a file of tcl commands that when sourced in the second process will update the variables you require.
Your final example is creating a single process and communicating via emulated keystrokes. This is really slow and error prone. There is a winsend package that can let you send messages to tcl interpreters from vbscript. There might be some others as part of TWAPI that can let you register the interpreter for external access.

Is there any method to detect whether STDIN has been redirected within VBscript?

I'm trying to process/filter input within a VBscript, but only if the input has been piped into the script. I don't want the script processing user/keyboard input. I'd like to code this as something like this:
stdin_is_tty = ...
if not stdin_is_tty then
...
input = WScript.StdIn.ReadAll
end if
Otherwise, the script will hang, waiting on user input when it executes WScript.StdIn.ReadAll (or even earlier if I test the stream with WScript.StdIn.AtEndOfStream).
In C#, I'd use:
stdin_is_tty = not System.Console.IsInputRedirected // NET 4.5+
The accepted answer for Q: "How to detect if Console.In (stdin) has been redirected?" shows how to build that result using Win32 calls via P/Invoke, for versions of NET earlier than NET 4.5. But I don't know of any way to translate that method into VBscript.
I've constructed a clumsy, partial solution using SendKeys to send an end-of-stream sequence into the scripts' keyboard buffer. But the solution leaves keys in the buffer if STDIN is redirected, which I can't clean up unless I know that STDIN was redirected... so, same problem.
I'd prefer to keep the script in one packaged piece, so I'd rather avoid a separate wrapping script or anything not available on a generic Windows 7+ installation.
Any brilliant ideas or workarounds?
EDIT: added copy of initial solution
I've added a copy of my improved initial solution here (admittedly, a "hack"), which now cleans up after itself but still has several negatives:
input = ""
stdin_is_tty = False
test_string_length = 5 ' arbitrary N (coder determined to minimize collision with possible inputs)
sendkey_string = ""
test_string = ""
for i = 1 to test_string_size
sendkey_string = sendkey_string & "{TAB}"
test_string = test_string & CHR(9)
next
sendkey_string = sendkey_string & "{ENTER}"
wsh.sendkeys sendkey_string ' send keyboard string signal to self
set stdin = WScript.StdIn
do while not stdin.AtEndOfStream
input = input & stdin.ReadLine
if input = test_string then
stdin_is_tty = True
else
input = input & stdin.ReadAll
end if
exit do
loop
stdin.Close
if not stdin_is_tty then
set stdin = fso.OpenTextFile( "CON:", 1 )
text = stdin.ReadLine
stdin.Close
end if
This solution suffers from the three problems:
leaving a visible trace at the command line (though now, just a single blank line which is low visibility)
possible collision of the test string (a set series of N [coder determined] TABs followed by a NEWLINE) with the first line of any redirected input causing a false positive redirection determination. Since the number of TABs can be modified, this possibility can be made arbitrarily low by the coder.
a race condition that if another window receives focus before the SendKeys portion is executed, the wrong window will receive the code string, leading to a false negative redirection determination. My estimate is that the possibility of this circumstance occurring is very low.
In short, no, but ...
I've tested everything i could think of and have not found a reasonable way to do it.
None of the properties/methods exposed by the TextStream wrappers retrieved with WScript.StdIn or fso.GetStdStream give enough information to determine if the input is redirected/piped.
Trying to obtain information from the behaviour/environment of a spawned process (how to create the executable is other story) is also unlikely to be useful because
WshShell.Execute always spawns the process with its input and output handles redirected
WshShell.Run creates a new process that does not inherit the handles of the current one
Shell.Application.ShellExecute has the same problem as WshShell.Run
So, none of these methods allow the spawned process to inherit the handles of the current process to check if they are redirected or not.
Using WMI to retrieve information from the running process does not return anything usable (well, HandleCount property for the process differs when there is a redirection, but it is not reliable)
So, not being able to determine from vbs code if there is a redirection, the remaining options are
Don't detect it: If the piped input must be present, behave as the more command and in all cases try to retrieve it
Indicate it: If the pipe input is not always required, use an argument to determine if the stdin stream needs to be read.
In my case, I usually use a single slash / as argument (for coherence with some of the findstr arguments that also use a slash to indicate stdin input). Then in the vbs code
If WScript.Arguments.Named.Exists("") Then
' here the stdin read part
End If
Check before: Determine if there is redirection before starting the script. A wrapper .cmd is needed, but with some tricks both files (.cmd and .vbs) can be combined into one
To be saved as .cmd
<?xml : version="1.0" encoding="UTF-8" ?> ^<!------------------------- cmd ----
#echo off
setlocal enableextensions disabledelayedexpansion
timeout 1 >nul 2>nul && set "arg=" || set "arg=/"
endlocal & cscript //nologo "%~f0?.wsf" //job:mainJob %arg% %*
exit /b
---------------------------------------------------------------------- wsf --->
<package>
<job id="mainJob">
<script language="VBScript"><![CDATA[
If WScript.Arguments.Named.Exists("") Then
Do Until WScript.StdIn.AtEndOfStream
WScript.StdOut.WriteLine WScript.StdIn.ReadLine
Loop
Else
WScript.StdOut.WriteLine "Input is not redirected"
End If
]]></script>
</job>
</package>
It is a .wsf file stored inside a .cmd. The batch part determines if the input is redirected (timeout command fails to get a console handle on redirected input) and pass the argument to the script part.
Then, the process can be invoked as
< inputfile.txt scriptwrapper.cmd input redirected
type inputfile.txt | scriptwrapper.cmd input piped
scriptwapper.cmd no redirection
While this is a convenient way to handle it, the invocation of the .wsf part from the .cmd, while being stable and working without problems, relies in an undocumented behaviour of the script host / cmd combination.
Of course you can do the same but with two separate files. Not as clean, but the behaviour is documented.

"Object required" when using Set in an assignment

call main()
sub main()
Dim scmd
Set scmd = "c:\windows\system32\cscript.exe //nologo c:\s.vbs"
createobject("wscript.shell").run scmd,0,false
end sub
It gives me error:
Object required: '[string: "c:\windows\system32\"]' Code 800A01A8
Update
As it's not clear feel it best to point out your Object Required issue is due to this line
Set scmd = "c:\windows\system32\cscript.exe //nologo c:\s.vbs"
This is because an Object is expected but you are assigning it a string, by removing the Set your code will work (As Ekkehard.Horner has pointed out).
Below is my interpretation of situation. First looking at your code it almost looked like it had mixed the instantiation of the WScript.Shell object with the command line for the .Run() method. It was my first stab at breaking down the code, rearranging it then putting it back together.
Original Answer
Your Set scmd should be instantiating the WScript.Shell (As Ekkehard.Horner points out you can use Server.CreateObject("WScript.Shell").Run for a one off reference but I wouldn't recommend it).
The .Run() should be executed by the instantiated scmd object and passed the command line to execute.
Here is an example I've renamed some of the variables (scmd to cmd for example).
Call main()
Sub main()
'Renamed variables to cmd is your object and cmdline is your file path.
Dim cmd, cmdline
'Instantiate WshShell object
Set cmd = Server.Createobject("WScript.Shell")
'Set cmdline variable to file path
cmdline = "c:\windows\system32\cscript.exe //nologo c:\s.vbs"
'Execute Run and return immediately
Call cmd.Run(cmdline, 0, False)
End Sub
Things to consider
When using WScript.Shell in Classic ASP to run executables there are some things to consider;
Run command will execute using the current Application Pool identity.
Run will execute the executable on the server not at the client (server side).
As
>> WScript.Echo CreateObject("WScript.Shell").CurrentDirectory
>>
E:\trials\SoTrials\answers\trials\AlgoTaBu\SuSo\wsf
proves, there is no rule or law at all that "Your Set scmd should be instantiating the WScript.Shell". Putting the command to execute in string variable scmd (or perhaps better sCmd) and not creating a variable for an only-once-used value are good practices.
The revised version (minus the stupid Set):
call main()
sub main()
Dim scmd
scmd = "c:\windows\system32\cscript.exe //nologo c:\s.vbs"
createobject("wscript.shell").run scmd,0,false
end sub
will work just as well as Lankymart's version.
To spell everything out:
The Set keyword, its semantic, and its error message are design flaws, that make VBScript harder to use correctly. "site:stackoverflow.com vbscript "object required" Set" results in 1500 hits. Even if much of those hits do not concern the "Set x = 'non-object' blunder, that's clearly too much. To explain/excuse those IEDs you have to consider that BASIC is a stone age language.
A person learning VBScript is entitled to be surprised by the "Set x = 'non-object' mistake twice. If it happens trice (or more often), he/she should be ashamed (and keep silent about it). Above all that problem should not pollute this site.
When I posted my contribution, all answers/comments - with the exception of Alex K.'s 'Just delete the Set' - emphasized/concentrated on the .Run statement; one answer called the script "topsy curvy", one answer even repeated the atrocity. So I tried to point out that there is exactly one error: The spurious Set.
I failed miserably. Evidence: John Saunders changed the title from "VBScript error" (unspecific but true) to "“Object required” when calling Run on Wscript.Shell" (specific but wrong), Lankymart engaged in psychological/philological research to save the Set at the expense of the string.
My only hope: Everybody reading this will be so disgusted by my harping on the Set, that she/he from now on will think twice when typing:
wtf
Set x = " ---- stop or be damned!!!
Set x = obj.getNumber() + 4 ---- oh no!!!
All to no avail - Same mistake again
I am not sure, try change
Set scmd = "c:\windows\system32\cscript.exe //nologo c:\s.vbs"
to
Set scmd = "c:\windows\system32\cscript.exe" //nologo "c:\s.vbs"

Is the Sleep operation no longer used in VBscript?

The "Sleep" command as stated in many places over the internet (including here on this forum) DOES NOT WORK. Is it now an obsolete command?
I am writing the VBScript code like this:
sub button1_onclick()
Wscript.Sleep 1000
div1.innerHTML = textbox1.value
end sub
It should wait 1 second and then execute that simple command. This is an utterly simple statement but it does not work. Plain and simple. It comes up with an error every time saying:
Object Required: 'Wscript'
Daniel's answer is absolutely correct about context being the key here. Although you don't have the WScript method available, you do have the full browser DOM, including the window.setTimeout method. With VBScript, the semantics of passing code to setTimeout are a little bit different than JavaScript, but it's still possible:
Sub button1_onclick()
window.setTimeout GetRef("Delayed"), 1000
End Sub
Sub Delayed()
div1.innerHTML = textbox1.value
End Sub
Another option would be to (ab)use ping (if you want to avoid an additional script):
Sub Sleep(seconds)
CreateObject("WScript.Shell").Run "%COMSPEC% /c ping 127.0.0.1 -n " _
& seconds+1, 0, True
End Sub
ping sends echo requests in (roughly) 1 second intervals, so you can get an n-second delay by sending n+1 echo requests.
When run from a browser, VBScript code does not have a Wscript object. This is only for stand-alone VBS. As such, Wscript.Sleep isn't obsolete, it just doesn't work in a browser without a work around.
This thread suggests a potential work around. The rest of this post comes from the entry by mayayana on the linked page:
If your security can allow WScript.Shell to run
you can do it this way -
Script sub in webpage:
<SCRIPT LANGUAGE="VBScript">
Sub Sleep(NumberSeconds)
Dim SH, Ret
Set SH = CreateObject("WScript.Shell")
Ret = SH.Run("sleeper.vbs " & NumberSeconds, , True)
End Sub
</SCRIPT>
In the same folder as the webpage, put a file named
sleeper.vbs and put this code into it:
Dim Arg
on error resume next
Arg = WScript.Arguments(0) * 1000
WScript.sleep Arg
You can then call something like:
Sleep 5 '-- pauses 5 seconds.

Resources