Script running infinitely when calling wscript.exe from code
Tom Tyson
The following call suddenly causes the script to run infinetely:
CreateObject("Wscript.Shell").Run "wscript.exe " &
Wscript.ScriptFullName
It seems it calls the script over and over, but there is only one instance
of wscript.exe running in Task Manager. However, I can see from the cpu
utilization and mouse pointer that the system is busy.
I have been using the script in which I use this for ages and it always
worked. Whats going on here?
Please see the following example of how I use the call:
--------------
Option Explicit
Main
Wscript.Quit 0
Sub Main()
If Instr(1, Wscript.FullName, "cscript", 1) = 0 Then
CreateObject("Wscript.Shell").Run "wscript.exe " &
Wscript.ScriptFullName
Wscript.Quit
End If
End Sub
---------------
This used to work and i did not modify anything!
Regards,
Tom
Pegasus [MVP]
"Tom Tyson" <n...@spam.org> wrote in message
news:hcmi0o$dlu$1...@newsreader2.netcologne.de...
Perhaps you did modify something. If you want to force your script to run
under wscript.exe then the line
If Instr(1, Wscript.FullName, "cscript", 1) = 0
should probably read
If Instr(1, Wscript.FullName, "cscript", 1) > 0
Todd Vargo
Interesting, I posted a similar (but working) code just last week. Your
version will work if you either change the "=" to ">" or remove the "= 0"
part entirely.
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
Al Dunbar
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
news:OV0wd0A...@TK2MSFTNGP05.phx.gbl...
Precisely.
But note also that, if, for some reason, the scripting executables were
relocated to a folder whose path contained the string "cscript", then instr
would detect even a wscript-based session falsely as a cscript one. While
not a highly likely scenario, this does suggest that perhaps the method of
detecting the scripting engine could be made somewhat more bullet proof.
/Al
Todd Vargo
> Todd Vargo wrote:
> > Tom Tyson wrote:
...
> >> If Instr(1, Wscript.FullName, "cscript", 1) = 0 Then
> >> CreateObject("Wscript.Shell").Run "wscript.exe " &
> >> Wscript.ScriptFullName
> >> Wscript.Quit
> >> End If
> >>
> >> End Sub
> >> ---------------
> >>
> >> This used to work and i did not modify anything!
> >
> > Interesting, I posted a similar (but working) code just last week. Your
> > version will work if you either change the "=" to ">" or remove the "=
0"
> > part entirely.
>
> Precisely.
>
> But note also that, if, for some reason, the scripting executables were
> relocated to a folder whose path contained the string "cscript", then
instr
> would detect even a wscript-based session falsely as a cscript one. While
> not a highly likely scenario, this does suggest that perhaps the method of
> detecting the scripting engine could be made somewhat more bullet proof.
Note, the code that I posted last week included the extension. There is no
such thing as bullet proof, but this modification eliminates the unlikely
possibility of the path including the extension too. The only way this could
fail now is if wscript is renamed or not found in PATH.
If Not Right(Wscript.FullName, 12) = "\WSCRIPT.EXE" Then
CreateObject("Wscript.Shell").Run "wscript.exe " & Wscript.ScriptFullName
Wscript.Quit
End If
--
Al Dunbar
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
and, apparently, the preceding backslash...
> There is no
> such thing as bullet proof, but this modification eliminates the unlikely
> possibility of the path including the extension too.
That's not the only scenario. What if one of the folders in the path were
named "\cscript.executables\"?
> The only way this could
> fail now is if wscript is renamed or not found in PATH.
Having renamed system executables would seem to be so likely to break a
system that it would be reasonable, and even responsible, to ignore that
possibility. The consequences would then belong to the perpetrator.
Of course, one could always examine the two registry values here:
"\\hklm\software\microsoft\windows scripting host\locations" to see how the
files are named and where they reside. A bit drastic, though. And of course,
if someone is renaming the executables, they might also rename the keys
pointing to them...
> If Not Right(Wscript.FullName, 12) = "\WSCRIPT.EXE" Then
> CreateObject("Wscript.Shell").Run "wscript.exe " & Wscript.ScriptFullName
> Wscript.Quit
> End If
Why not use the File System Object's GetFileName and GetFileExtensionName
methods?
Anyway, my previous point was not that we need to worry about unusual
configurations, just that a little more precision in how we parse and
compare filenames would be a good habit to develop.
/Al
mayayana
> If Not Right(Wscript.FullName, 12) = "\WSCRIPT.EXE" Then
> CreateObject("Wscript.Shell").Run "wscript.exe " &
Wscript.ScriptFullName
> Wscript.Quit
> End If
>
While we're splitting hairs...:)
I think you also need UCase there. You can
search for a file case-insensitive but string
operations are at root numeric and therefore
case-sensitive:
Dim s
s = "abcd"
If Right(s, 2) = "CD" Then
MsgBox "Match."
Else
MsgBox "No match."
End If
WScript.exe is named with all caps on my PC,
but I wouldn't want to depend on that. Microsoft
seems to be fairly willy nilly about that sort of thing.
(The other day I downloaded a VB6 service pack
full of .ocx files. The file extensions alone had at
least 3 different cap. versions: .ocx, .OCX, .Ocx )
Todd Vargo
"mayayana" <mayaX...@rcXXn.com> wrote in message
news:uElVOiVX...@TK2MSFTNGP06.phx.gbl...
FWIW, I checked prior to posting. Wscript.FullName always returns upper case
(on my Win98 system at least) regardless of actual host name. For my
testing, I created a copy of each host and renamed it to "Foo_Bar_Baz.exe"
and ran this.
Wscript.Echo Wscript.FullName
The full LFN was returned in all caps.
Todd Vargo
> Todd Vargo wrote:
>
> > There is no
> > such thing as bullet proof, but this modification eliminates the
unlikely
> > possibility of the path including the extension too.
>
> That's not the only scenario. What if one of the folders in the path were
> named "\cscript.executables\"?
Your original point was well taken, hence, the modification used Right()
instead of Instr(). However, I must say, you are really streching this quite
far and thin just to find faults.
>
> > The only way this could
> > fail now is if wscript is renamed or not found in PATH.
>
> Having renamed system executables would seem to be so likely to break a
> system that it would be reasonable, and even responsible, to ignore that
> possibility. The consequences would then belong to the perpetrator.
That is why I modified it to test for the exact host desired to run instead
of testing if the wrong one was used. If Wscript.exe were to be renamed,
.Run method will report the absence of wscript.exe regardless of which host
started the script.
>
> Of course, one could always examine the two registry values here:
> "\\hklm\software\microsoft\windows scripting host\locations" to see how
the
> files are named and where they reside. A bit drastic, though. And of
course,
> if someone is renaming the executables, they might also rename the keys
> pointing to them...
Of course, looking at keys in the registry does not tell you which host is
actually running the script, the real purpose for the code in the first
place.
>
> > If Not Right(Wscript.FullName, 12) = "\WSCRIPT.EXE" Then
> > CreateObject("Wscript.Shell").Run "wscript.exe " &
Wscript.ScriptFullName
> > Wscript.Quit
> > End If
>
> Why not use the File System Object's GetFileName and GetFileExtensionName
> methods?
What is wrong with using Wscript.FullName? I don't see how your suggestion
improves the code.
>
> Anyway, my previous point was not that we need to worry about unusual
> configurations, just that a little more precision in how we parse and
> compare filenames would be a good habit to develop.
Again, your original point was well taken. Frankly, I expected some
nit-picky code basher to complain about the absence of argument handling in
the restart code, not that someone could possibly relocate the host
executables.
Pegasus [MVP]
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
> Al Dunbar wrote:
>> Todd Vargo wrote:
>>
>> > There is no
>> > such thing as bullet proof, but this modification eliminates the
> unlikely
>> > possibility of the path including the extension too.
>>
>> That's not the only scenario. What if one of the folders in the path were
>> named "\cscript.executables\"?
>
> Your original point was well taken, hence, the modification used Right()
> instead of Instr(). However, I must say, you are really streching this
> quite
> far and thin just to find faults.
>
(Grin). Meet the resident nit-picker.
Al Dunbar
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
> Al Dunbar wrote:
>> Todd Vargo wrote:
>>
>> > There is no
>> > such thing as bullet proof, but this modification eliminates the
> unlikely
>> > possibility of the path including the extension too.
>>
>> That's not the only scenario. What if one of the folders in the path were
>> named "\cscript.executables\"?
>
> Your original point was well taken, hence, the modification used Right()
> instead of Instr(). However, I must say, you are really streching this
> quite
> far and thin just to find faults.
Agreed about the "quite far", though not too far for the purpose, which was
never to find fault with anyone, as I implied by saying: "Anyway, my
previous point was not that we need to worry about unusual configurations,
just that a little more precision in how we parse and compare filenames
would be a good habit to develop."
<snip>
>> Of course, one could always examine the two registry values here:
>> "\\hklm\software\microsoft\windows scripting host\locations" to see how
> the
>> files are named and where they reside. A bit drastic, though. And of
> course,
>> if someone is renaming the executables, they might also rename the keys
>> pointing to them...
>
> Of course, looking at keys in the registry does not tell you which host is
> actually running the script, the real purpose for the code in the first
> place.
Of course not. You'd still use .fullname to determine the name of the
executable, and query the registry to see if it was a match to either the
cscript or wscript key. My registry suggestion was more to hint at the
silliness of taking things much farther than realistically reasonable. ;-)
>>
>> > If Not Right(Wscript.FullName, 12) = "\WSCRIPT.EXE" Then
>> > CreateObject("Wscript.Shell").Run "wscript.exe " &
> Wscript.ScriptFullName
>> > Wscript.Quit
>> > End If
>>
>> Why not use the File System Object's GetFileName and GetFileExtensionName
>> methods?
>
> What is wrong with using Wscript.FullName? I don't see how your suggestion
> improves the code.
I didn't say it would improve the code, I just asked why not use those
methods. Your answer would appear to be: "because it would not improve the
code". I'd even agree that, in this case, the results are equivalent.
It is just my contention that it is generally better practice to use the
supplied properties to parse filename paths than to write code to parse
them. Using the RIGHT function to compare the filename against a possible
value requires the length of the filename string to be included, either
literally or using the LEN function.
>>
>> Anyway, my previous point was not that we need to worry about unusual
>> configurations, just that a little more precision in how we parse and
>> compare filenames would be a good habit to develop.
>
> Again, your original point was well taken. Frankly, I expected some
> nit-picky code basher to complain about the absence of argument handling
> in
> the restart code, not that someone could possibly relocate the host
> executables.
I thought to leave that to someone else ;-)
/Al
Todd Vargo
> Todd Vargo wrote:
> >> Why not use the File System Object's GetFileName and
GetFileExtensionName
> >> methods?
> >
> > What is wrong with using Wscript.FullName? I don't see how your
suggestion
> > improves the code.
>
> I didn't say it would improve the code, I just asked why not use those
> methods. Your answer would appear to be: "because it would not improve the
> code". I'd even agree that, in this case, the results are equivalent.
Unfortuntly, I can not read your mind so you will have to show me with code
what you had in mind that provides equivalent results.
>
> It is just my contention that it is generally better practice to use the
> supplied properties to parse filename paths than to write code to parse
> them. Using the RIGHT function to compare the filename against a possible
> value requires the length of the filename string to be included, either
> literally or using the LEN function.
I used a hard coded, expected value, not a "possible value", and did not use
LEN so you lost me. Please show code examples of what exactly you are
talking about here. Using phrases like "generally better practice" and "a
little more precision in how we parse and compare filenames would be a good
habit to develop", is not the same as showing code that actually does it. I
would like to see your code that demonstrates these phrases in a "somewhat
more bullet proof" way than my last example.
Tom Tyson
still want the output to go to the command prompt. The fragment I posted did
the job just fine as long as i switched the wsh engine to cscript before
execution. I admit I haven't put much thought into this.
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
news:OV0wd0A...@TK2MSFTNGP05.phx.gbl...
Al Dunbar
> I am a developer new to WSH. I want to use Wscript objects in the script
> but still want the output to go to the command prompt. The fragment I
> posted did the job just fine as long as i switched the wsh engine to
> cscript before execution. I admit I haven't put much thought into this.
If you are running your scripts from the command prompt or from within a
batch file, try starting them with this command:
cscript //nologo myscript.wsf
or myscript.vbs}
cscript //nologo myscript.vbs
/Al
asdf
Was answered by Al
------------------------------------------------
Tom is happy
"Al Dunbar" <alan...@hotmail.com> wrote in message
news:O9N1EAZa...@TK2MSFTNGP05.phx.gbl...
Tom Tyson
thanks for your input. The problem was that for some reason, Windows used
WScript to run the script even though i manually set the script host to
CScript prior to running the script, which caused the output to be displayed
in message boxes rather than in the console. This is weird and has been
observed recently on 3 out of 10 systems we use the script on. Like I said,
I did not make any modifications to the script and it has worked for years.
I found that on the affected machines, Windows changes the associated
default action for the file type .vbs, "Open with Command Prompt", to point
to WScript.exe rather than CScript.exe. This is not the expected behavior
after running WScript //H:Cscript.
After changing the associated action command back to CScript, the
(unmodified) script works fine again, writing all WScript.echo output to the
command line.
Tom
"Tom Tyson" <n...@spam.org> wrote in message
news:hcmi0o$dlu$1...@newsreader2.netcologne.de...
Pegasus [MVP]
The underlying problem seems to be that your overall script or batch file
relies on assumptions. When you want an application to be robust then you
must make as few assumptions as possible. Instead of invoking your script
like so:
c:\Tools\MyScript.vbs
you should invoke it like so:
cscript //nologo c:\Tools\MyScript.vbs
"Tom Tyson" <n...@spam.org> wrote in message
news:hrmfn2$bvg$1...@newsreader5.netcologne.de...
Todd Vargo
> Hi all,
>
> thanks for your input. The problem was that for some reason, Windows
> used WScript to run the script even though i manually set the script host
> to CScript prior to running the script, which caused the output to be
> displayed in message boxes rather than in the console. This is weird and
> has been observed recently on 3 out of 10 systems we use the script on.
> Like I said, I did not make any modifications to the script and it has
> worked for years.
>
> I found that on the affected machines, Windows changes the associated
> default action for the file type .vbs, "Open with Command Prompt", to
> point to WScript.exe rather than CScript.exe. This is not the expected
> behavior after running WScript //H:Cscript.
>
> After changing the associated action command back to CScript, the
> (unmodified) script works fine again, writing all WScript.echo output to
> the command line.
>
> Tom
From what you say above, it appears that you want to force the script to
only run using CSCRIPT.EXE but some some reason your code is written to
force WSCRIPT.EXE instead.
If Instr(1, Wscript.FullName, "\cscript.exe", 1) = 0 Then
CreateObject("Wscript.Shell").Run "cscript.exe " & Wscript.ScriptFullName
Wscript.Quit
End If
--
Tom Tyson
for the moment. I realize I should call the script your way, but doing so
would require further changes to the surrounding code and redistribution.
I'll rather not go there, since I am not familiar with WSH and don't want
you guys to do my homework :)
"Pegasus [MVP]" <ne...@microsoft.com> wrote in message
news:ujOjNnt6...@TK2MSFTNGP04.phx.gbl...
Tom Tyson
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
Todd,
this does not make a difference. If the explorer default action for vbs
files is set to Wscript instead of Cscript, your version won't work. Passing
a vbs file to cscript.exe will still cause the output to be displayed in
window mode rather than console. I do not know how this mapping has been
tampered with on some machines, while not on others. Same OS version, SP
level etc. I've read similar reports from other users on the web.
Thanks,
Tom
Todd Vargo
>
> this does not make a difference. If the explorer default action for vbs
> files is set to Wscript instead of Cscript, your version won't work.
> Passing a vbs file to cscript.exe will still cause the output to be
> displayed in window mode rather than console. I do not know how this
> mapping has been tampered with on some machines, while not on others. Same
> OS version, SP level etc. I've read similar reports from other users on
> the web.
Oh, you wanted the window to remain open after the script completes (guess I
missed that). You can either append a MsgBox statement to the end of the
script or insert "cmd.exe /k" in the .Run command as below.
If Instr(1, Wscript.FullName, "\cscript.exe", 1) = 0 Then
CreateObject("Wscript.Shell").Run "cmd.exe /k cscript.exe " &