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
> 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
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
> 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!
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)
>> 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!
> 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.
Al Dunbar wrote: > 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
-- Todd Vargo (Post questions to group only. Remove "z" to email personal messages)
> Al Dunbar wrote: >> 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.
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.
> 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 )
> > 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 )
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 (Post questions to group only. Remove "z" to email personal messages)
> > 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.
-- Todd Vargo (Post questions to group only. Remove "z" to email personal messages)
>> > 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.
>> > 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.
Al Dunbar wrote: > Todd Vargo wrote: > > Al Dunbar 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.
-- Todd Vargo (Post questions to group only. Remove "z" to email personal messages)
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.
"Todd Vargo" <tlva...@sbcglobal.netz> wrote in message
>> 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!
> 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)
> 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:
>>> 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!
>> 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)
> "Tom Tyson" <n...@spam.org> wrote in message > news:he4l7s$fbd$1@newsreader2.netcologne.de... >> 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:
>>>> 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!
>>> 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)
|
