About scripting?

[vefatica]

I'm getting a bit confused. Here's a little script, printdir.vbs.

v:\> Dim WshShell, command, tempdir, tempfile
Set WshShell = wscript.createobject("Wscript.Shell")
Set objArgs = WScript.Arguments
tempdir = WshShell.ExpandEnvironmentStrings("%temp%")
tempfile = tempdir & "\dirlist.txt"
command = "cmd /c dir /a " & Chr(34) & objArgs(0) & Chr(34) & " > " &Chr(34) & tempfile & Chr(34)
WScript.Echo command
WshShell.Run command

If I run it with WSCRIPT (TCC or Start/Run)

C:\Windows\system32\wscript.EXE u:\printdir.vbs v:\monitor.txt

it works, with the output of WScript.Echo going to a message box.

If I run it with CSCRIPT (TCC or Start/Run)

C:\Windows\system32\cscript.EXE u:\printdir.vbs v:\monitor.txt

it also works, with the output going to the console.

All that is expected.

If I run it by name from TCC (or Start/Run)

u:\printdir.vbs v:\monitor.txt

it works with the Echo going to a message box. That is, it's run by WSCRIPT.EXE (confirmed via TaskMgr). That's odd because I have

v:\> assoc .vbs
.vbs=VBSFile

v:\> ftype vbsfile
vbsfile="C:\Windows\System32\CScript.exe" "%1" %*

The second oddity occurs when I run it with TCC's SCRIPT

script u:\printdir.vbs v:\monitor.txt

It doesn't work. I get these, one after the other.

So I guess there are two questions. (1) Why, when I run it by name, do I get WSCRIPT instead of the associated CSCRIPT?
(2) Why can't I run it with SCRIPT?

 

[vefatica]

Here's another oddity.

v:\> ver & ftype vbsfile

TCC  23.00.25   Windows 7 [Version 6.1.7601]
vbsfile="C:\Windows\System32\CScript.exe" "%1" %*

v:\> cmd /c ver ^& ftype vbsfile

Microsoft Windows [Version 6.1.7601]
vbsfile="%SystemRoot%\System32\WScript.exe" "%1" %*

 

[samintz]

On my Win10 PC, under HCR/VBSFile/Shell, I have Open and Open2. Open/Command is WScript. And Open2/Command is CScript. The description for Open is Open and the description for Open2 is Open with Command Prompt.

 

[vefatica]

On my Win10 PC, under HCR/VBSFile/Shell, I have Open and Open2. Open/Command is WScript. And Open2/Command is CScript. The description for Open is Open and the description for Open2 is Open with Command Prompt.

I have the same.

 

[rconn]

Here's another oddity.

v:\> ver & ftype vbsfile

TCC  23.00.25   Windows 7 [Version 6.1.7601]
vbsfile="C:\Windows\System32\CScript.exe" "%1" %*

v:\> cmd /c ver ^& ftype vbsfile

Microsoft Windows [Version 6.1.7601]
vbsfile="%SystemRoot%\System32\WScript.exe" "%1" %*

WAD. TCC uses \SHELL\\OPEN2\COMMAND, because that's what Microsoft says (non-ancient) apps are supposed to use. CMD never got the message.

 

[rconn]

So I guess there are two questions. (1) Why, when I run it by name, do I get WSCRIPT instead of the associated CSCRIPT?
(2) Why can't I run it with SCRIPT?

1) Because that's what the Windows API (AssocQueryString) is returning.

2) You can't run it with SCRIPT because you're inventing a syntax that SCRIPT doesn't support. SCRIPT only accepts filenames; you cannot pass arguments. So the errors are coming from the ActiveScripting host complaining about the script name "v:\monitor.txt".

And yes, I agree it would be nice if ActiveScripting accepted arguments. Complain to Microsoft - they'll probably tell you something useful like "we don't support ActiveScripting anymore".

 

[Larry_Brasfield]

Just as the Wscript.Shell interface is able to parse its invoking command tail and make arguments available to a script, the 'TakeCommand' interface, which is available when the 'script' command is running a script, could parse its command tail and make arguments available.

I'm not so sure that it is really the place of ActiveScripting to handle command-line argument issues. It is much more general-purpose than would require such a feature. The Wscript.Shell interface to the engine host (when Wscript or Cscript is the host) seems quite sensible to me, and so would TCC doing the same (or better.) That improvement, along with making script exit status available, would make the 'script' command more of a regular feature rather than looking like an after-thought.

 

[rconn]

First, the TCC script support doesn't use Wscript.Shell, it uses IActiveScript (which doesn't support command line args).

Second, active scripting has been deprecated & unsupported by Microsoft for (many!) years. The support in TCC is for legacy scripts; there is no point in my trying to make "improvements" to something that Microsoft is actively trying to break. (It was broken for months after the Win 10 release.)

 

[LarryBrasfield]

Rex, I do not dispute your assertion that IActiveScript provides no support for command line arguments. My point was that such support would go outside of the purpose of that interface, which is to provide a way for applications generally, (not just shells), to be scripted using scripting engines. I was simply countering your argument that the 'script' command's inability to pass arguments to a script was attributable to a deficiency of the scripting engine interface, which argument is contradicted by the existence of that capability in Wscript.Shell, a capability which TCC could emulate.

Given that the 'script' command is effectively orphaned, relying on a technology not being further developed by Microsoft, lacking the features generally understood to be necessary for scripting [a], and unlikely to be made into a normal member of the TCC feature set , I think it would be better for TCC users to avoid using the 'script' command or relax their expectations regarding it.

[a. Those features are a way to pass values into a script invocation and a way to return values back from it. The environment, shared between the invoking TCC and the running script, is a very clumsy channel for passing those values. ]
[b. By the 'normal' TCC features, I mean the ones which are well integrated with TCC, documented well enough to be useful, and designed to be used conveniently to solve the problems for which TCC is well suited. ]