"Tom Lavedas" <> wrote in message
news:0e2e09ff-9d77-4509-8265-...
> On Feb 18, 2:38 pm, "Pegasus [MVP]" <n...@microsoft.com> wrote:
>> "John H." <johnheitmul...@gmail.com> said this in news
>> itemnews:94092298-b71b-48d4-b588-...
>>
>> > Okay, I got that to work. Thanks. The scripts that I want to run
>> > require cscript.exe as a script host. Since the default script host
>> > is wscript.exe I was getting an error when I ran the .vbs file
>> > directly from the command line. So I ran cscript.exe /H:cscript to
>> > change the default. Now I can just run the .vbs file from the command
>> > line. Very cool!
>>
>> > Is there a down side to changing my default script host to cscript.exe
>> > that might trip me up later?
>>
>> > Thanks,
>> > John
>>
>> None that I'm aware of.
>
> Maybe a tiny one, if the OP dislikes command console windows popping
> up anywhere as much as I do. Of course, this only happens when a
> procedure is launched by dropping a file onto it or a shortcut that
> points to it. Or when it is run by double-clicking in explorer.
> Other than that, there's probably no other downside.
Agreed. The downside is that most of us (and most of our scripts) assume
that the default is wscript.exe.
But the OP could modify his script to first determine which scripting engine
is being run, and re-run itself with cscript if if finds it is being run by
wscript. Then he can start the script by any method, whether by
double-clicking or typing scriptname.vbs at a prompt.
Alternately, he could create a non-standard filename extension (.vbsC) and
associate that with cscript.
/Al
|