WSC: Using wscript.echo, .quit, etc. in a script component

Can anyone tell me why Wscript.Echo, Wscript.Quit, and Wscript.Scriptname
don't work in Windows Script Components?

Thanks,
Ed

Alex
Wed Jan 21 09:15:46 CST 2004

Because WScript doesn't mean anything to a WSC. They are generic COM classes
without direct access to their hosting application's objects.

If you're writing a WSH-specific WSC and want access to these methods, you
can pass a reference to WScript into the WSC as an argument to a property or
function/sub. That's what I did with a WSC designed to offload generic
pre-processing of script arguments and host validation.

To further ensure that your WSC doesn't have unexpected errors, I would
suggest that you test the typename of the reference passed in; for cscript
and wscript it should be "IHost_Class".

Ed Bachmann wrote:
> Can anyone tell me why Wscript.Echo, Wscript.Quit, and
> Wscript.Scriptname don't work in Windows Script Components?
>
> Thanks,
> Ed

Joe
Wed Jan 21 09:55:32 CST 2004

Hi,

To add a bit to Alex's post ...

"Ed Bachmann" <ed_bachmann@unc.edu> wrote in message
news:400e94b3$1_3@news.unc.edu...
| Can anyone tell me why Wscript.Echo, Wscript.Quit, and Wscript.Scriptname
| don't work in Windows Script Components?
|
| Thanks,
| Ed

The immediate WScript object methods and properties are designed to work
only where WSH is the host. WSH is the host only where wscript.exe and
cscript.exe are run directly. Otherwise, each scripting host that allows
VBS/JS accessess the various WSH DLL or OCX files, as that host is coded.
WSC is an XML scripting host. MS placed the immediate WScript host methods
and properties (only) in the WSH EXE files, themselves, so they are not
accessible from other scripting hosts. (Credit Tom Lavedas for a post with
this info.) By comparison, the fundamental WScript.Shell object and the Err
object are exposed through DLL or OCX files, and are available in other
hosts, when not suppressed for security reasons. MS apparently believes
that the immediate WScript methods and properties present a basic conflict
or security hazard with other hosts.

Here's some script that I use in my WSC library file for passing the WScript
object into a WSC file and setting a flag for internal use and verification
(using "oWsc" as the variable holding the declared WSC file object
instance):

From the calling VBS file script:
---
oWsc.wsh= wscript
---

In the WSC file:
---
...
<property name="Wsh" put="putWsh" />
...
' global level code
dim qWsh, oWsh
set oWsh= nothing
...
function putWsh (vo)
if isobject(vo) then
set oWsh= vo
on error resume next
oWsh.sleep 10: qWsh= (err=0)
on error goto 0
if NOT qWsh then set oWsh= nothing
end if
end function
---

Wsh object scope inside the WSC is, of course, limited to the duration of
the calling WSH-hosted VBS script, but this is generally not a problem,
since the WSC object scope, itself, will normally also be limited to the
duration of the calling WSH-hosted VBS script.

Joe Earnest



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.564 / Virus Database: 356 - Release Date: 01-19-04

Alex
Wed Jan 21 10:29:05 CST 2004

Joe Earnest wrote:
> Hi,
>
> To add a bit to Alex's post ...
> ... MS apparently believes that the immediate
> WScript methods and properties present a basic conflict or security
> hazard with other hosts.

Which indirectly reminds me of another point. The FileSystemObject class
also operates under security restrictions for probably the same general
reasons as Joe has suggested that WScript might be restricted for. In any
case, it is possible to use FSO to access the textstream-oriented elements
of WScript's I/O directly from an FSO instance.

This is only useful if running with CScript as your host executable, but if
all you need access to are StdIn, StdOut, and StdErr (not the case for you
unfortunately) you can do this purely from FSO with no need for the WScript
object, like this:

dim fso, cin, cout, cerr
set fso = createobject("Scripting.FileSystemObject")
set cin = fso.GetStandardStream(0)
set cout = fso.GetStandardStream(1)
set cerr = fso.GetStandardStream(2)

Joe
Wed Jan 21 10:46:54 CST 2004

Hi Alex,

"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:egEG4uD4DHA.536@tk2msftngp13.phx.gbl...

| Which indirectly reminds me of another point. The FileSystemObject class
| also operates under security restrictions for probably the same general
| reasons as Joe has suggested that WScript might be restricted for. In any
| case, it is possible to use FSO to access the textstream-oriented elements
| of WScript's I/O directly from an FSO instance.
|
| This is only useful if running with CScript as your host executable, but
if
| all you need access to are StdIn, StdOut, and StdErr (not the case for you
| unfortunately) you can do this purely from FSO with no need for the
WScript
| object, like this:
|
| dim fso, cin, cout, cerr
| set fso = createobject("Scripting.FileSystemObject")
| set cin = fso.GetStandardStream(0)
| set cout = fso.GetStandardStream(1)
| set cerr = fso.GetStandardStream(2)

Cool. Pardon my befuddled thinking this morning, but does this mean (as I
think it does) that I can use stdin, stdout and std err as methods in their
direct fso object guise from wsc and wscript hosts?

Regards,
Joe



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.564 / Virus Database: 356 - Release Date: 01-19-04

Alex
Wed Jan 21 11:29:49 CST 2004

Joe Earnest wrote:

>> dim fso, cin, cout, cerr
>> set fso = createobject("Scripting.FileSystemObject")
>> set cin = fso.GetStandardStream(0)
>> set cout = fso.GetStandardStream(1)
>> set cerr = fso.GetStandardStream(2)
>
> Cool. Pardon my befuddled thinking this morning, but does this mean
> (as I think it does) that I can use stdin, stdout and std err as
> methods in their direct fso object guise from wsc and wscript hosts?

If you mean without having a console already attached to the process, no.
But if there already is a console present, this gives you access to those
streams. So restricting the conversation to WSH, cscript still must be the
host; but any running application that is attached to a console and
instantiates FSO can use this.

Joe
Wed Jan 21 11:51:22 CST 2004

Hi Alex,

"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:u4PntQE4DHA.1728@TK2MSFTNGP09.phx.gbl...
| If you mean without having a console already attached to the process, no.
| But if there already is a console present, this gives you access to those
| streams. So restricting the conversation to WSH, cscript still must be the
| host; but any running application that is attached to a console and
| instantiates FSO can use this.

Unfortunately, it's the console and the need to run cscript that I wanted to
avoid. :-(

Thanks for the info.

Regards,
Joe



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.564 / Virus Database: 356 - Release Date: 01-19-04

Alex
Wed Jan 21 12:20:18 CST 2004

Joe Earnest wrote:
> Hi Alex,
>
> "Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
> news:u4PntQE4DHA.1728@TK2MSFTNGP09.phx.gbl...
>> If you mean without having a console already attached to the process,
>> no. But if there already is a console present, this gives you access
>> to those streams. So restricting the conversation to WSH, cscript
>> still must be the host; but any running application that is attached
>> to a console and instantiates FSO can use this.
>
> Unfortunately, it's the console and the need to run cscript that I
> wanted to avoid. :-(
>
> Thanks for the info.
>

There IS a new XP API which could be used if appropriately wrapped -
AttachConsole - but of course that doesn't do any good for this case.

One workaround I played with a bit was a generic GetTextStream function that
would automatically make some decisions based on getting errors returned
from attempts to read/write to the streams. Generic StdIn/StdOut/StdErr
objects are instantiated; if any fail, then they are automatically
redirected to files in the current directory with names like
wshin/wshout/wsherr. Still not pretty.

Joe
Wed Jan 21 14:00:15 CST 2004

Hi Alex,

"Alex K. Angelopoulos [MVP]" <aka-at-mvps-dot-org> wrote in message
news:uuPP7sE4DHA.2448@TK2MSFTNGP09.phx.gbl...
| There IS a new XP API which could be used if appropriately wrapped -
| AttachConsole - but of course that doesn't do any good for this case.
|
| One workaround I played with a bit was a generic GetTextStream function
that
| would automatically make some decisions based on getting errors returned
| from attempts to read/write to the streams. Generic StdIn/StdOut/StdErr
| objects are instantiated; if any fail, then they are automatically
| redirected to files in the current directory with names like
| wshin/wshout/wsherr. Still not pretty.

A clever idea. Now if we could just get a pseudo-file object that WSH would
accept for its TextStream methods, so that it would redirect to a variable,
an Ie window, the clipboard, etc. ...

Regards,
Joe



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.564 / Virus Database: 356 - Release Date: 01-19-04