Alex K. Angelopoulos wrote:

> Explain what you mean?
>
> It looks like an extension of the same problem - it works fine if the script
> is wrapped, if not, instead of dumping out an input pipe error it pops up
> the script in a separate window, prompting for input. :|

Ah. I haven't tested this extensively, but MSH is returning Win32 error
193 ("<whatever> is not a valid Win32 application"). Here's what I mean:

MSH C:\> get-content Test.js
var tsinput = WScript.StdIn, tsoutput = WScript.StdOut;

while (! tsinput.AtEndOfStream)
tsoutput.WriteLine(tsinput.ReadLine());
MSH C:\> get-childitem | Test.js
Program 'Test.js' failed to execute: The specified executable is not a
valid Win32 application.
At line:1 char:23
+ get-childitem | Test.js <<<< .
At line:1 char:1
+ g <<<< et-childitem | Test.js

This is a bit different than error 6 ("The handle is invalid"). MSH's
behavior, while IMHO not correct, at least makes sense at a beta stage:
The command at the beginning of the RHS of the pipe has to be an
executable (i.e., not a file that gets executed indirectly via an
association). Cmd.exe's behavior seems to be broken in a different manner.

--
Bill Stewart

Yeah, I'm seeing this too. This is worth posting as a bug in
windows.server.scripting with [MSH] in the title.

Even if it is going to mimic the behavior of cmd.exe for "compatibility"
reasons, the error message is misleading - it points away from the broken
input pipe problem.

It _does_ "work natively" if you explicitly run it with cscript as the host,
of course.

"Bill Stewart" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Alex K. Angelopoulos wrote:
>
>> Explain what you mean?
>>
>> It looks like an extension of the same problem - it works fine if the
>> script is wrapped, if not, instead of dumping out an input pipe error it
>> pops up the script in a separate window, prompting for input. :|
>
> Ah. I haven't tested this extensively, but MSH is returning Win32 error
> 193 ("<whatever> is not a valid Win32 application"). Here's what I mean:
>
> MSH C:\> get-content Test.js
> var tsinput = WScript.StdIn, tsoutput = WScript.StdOut;
>
> while (! tsinput.AtEndOfStream)
> tsoutput.WriteLine(tsinput.ReadLine());
> MSH C:\> get-childitem | Test.js
> Program 'Test.js' failed to execute: The specified executable is not a
> valid Win32 application.
> At line:1 char:23
> + get-childitem | Test.js <<<< .
> At line:1 char:1
> + g <<<< et-childitem | Test.js
>
> This is a bit different than error 6 ("The handle is invalid"). MSH's
> behavior, while IMHO not correct, at least makes sense at a beta stage:
> The command at the beginning of the RHS of the pipe has to be an
> executable (i.e., not a file that gets executed indirectly via an
> association). Cmd.exe's behavior seems to be broken in a different manner.
>
> --
> Bill Stewart

"Bill Stewart" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> .... The interesting point is your comment that "apparently the input pipe
> is broken." It seems so, but why? My suspicion is that cmd.exe is doing
> something wrong when it creates the process, but I've been unable to
> figure out exactly what (admittedly, I haven't spent that much time on
> it).

It's actually performing a ShellExecute() if the item is not "native" -
meaning if it isn't an executable or a cmd/bat file. Thus cmd.exe's
dependency on Shell32.dll and the fact that it always expands names for
things like this using the relevant registered handler.

This just "describes" the details of the bug, of course. It's ironic because
from what I can see via quick checking using Dependency Walker and Regmon on
4NT, it goes through almost precisely the same process as cmd.exe. It just
happens to deal with passing on the input stream the right way, whether
because it is doing an extra step of "hooking up" the input stream, or is
making sure handles get duplicated before the command is invoked.

If it is the second one, there is a chance that it might be possible to
"fix" this in MSH, since it has to do command parsing and could just as
easily perform the expansion.

> However, I should point out that redirection to WSH scripts works just
> fine in 4NT. (I rarely use cmd.exe interactively, so it took me a while to
> notice that this is broken in cmd.exe.)

I suspect that

Alex K. Angelopoulos wrote:

> It's actually performing a ShellExecute() if the item is not "native" -
> meaning if it isn't an executable or a cmd/bat file. Thus cmd.exe's
> dependency on Shell32.dll and the fact that it always expands names for
> things like this using the relevant registered handler.

Are you certain that it's really using ShellExecute? When I use an API
monitor, watch cmd.exe and search for Test.js (the "program" for the RHS
of the pipe), I see CreateProcess (which of course fails, because a
script isn't a Win32 executable), and then I see another CreateProcess
with cscript and Test.js as an argument. (Of course, I could be
"reading" it wrong...)

> This just "describes" the details of the bug, of course. It's ironic because
> from what I can see via quick checking using Dependency Walker and Regmon on
> 4NT, it goes through almost precisely the same process as cmd.exe. It just
> happens to deal with passing on the input stream the right way, whether
> because it is doing an extra step of "hooking up" the input stream, or is
> making sure handles get duplicated before the command is invoked.
>
> If it is the second one, there is a chance that it might be possible to
> "fix" this in MSH, since it has to do command parsing and could just as
> easily perform the expansion.

Yes, I came to basically the same conclusion...

--
Bill Stewart

"Bill Stewart" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Alex K. Angelopoulos wrote:
>
>> It's actually performing a ShellExecute() if the item is not "native" -
>> meaning if it isn't an executable or a cmd/bat file. Thus cmd.exe's
>> dependency on Shell32.dll and the fact that it always expands names for
>> things like this using the relevant registered handler.
>
> Are you certain that it's really using ShellExecute? When I use an API
> monitor, watch cmd.exe and search for Test.js (the "program" for the RHS
> of the pipe), I see CreateProcess (which of course fails, because a script
> isn't a Win32 executable), and then I see another CreateProcess with
> cscript and Test.js as an argument. (Of course, I could be "reading" it
> wrong...)

What API monitoring tool are you using? I'm curious because I've had little
luck with tracing the entire process for anything using Dependency Walker's
profiling.

I do not have solid proof that ShellExecute is used, and what you've seen
makes it look makes it very questionable. A ShellExecute call should
eventually result in a CreateProcess, but I think you would have seen the
earlier ShellExecute invocation if that was really happening.

Alex K. Angelopoulos wrote:

> What API monitoring tool are you using? I'm curious because I've had little
> luck with tracing the entire process for anything using Dependency Walker's
> profiling.

http://www.rohitab.com/apimonitor/

> I do not have solid proof that ShellExecute is used, and what you've seen
> makes it look makes it very questionable. A ShellExecute call should
> eventually result in a CreateProcess, but I think you would have seen the
> earlier ShellExecute invocation if that was really happening.

Yes, I do think that a ShellExecute probably eventually results in a
call to CreateProcess, but I'm not convinced that cmd.exe uses
ShellExecute directly.

If I'm reading the API monitor's output correctly, it looks like cmd.exe
first tries to call CreateProcess with the script file's name, which of
course fails. It looks like cmd.exe then determines the .js file
association and calls CreateProcess again with cscript.exe as the
executable name and the script file as its parameter (which looks
correct, as far as it goes). I'm not sure where in this process that the
input pipe gets broken, but I suspect that it's in the second call to
CreateProcess.

--
Bill Stewart

"Bill Stewart" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Alex K. Angelopoulos wrote:
>
>> What API monitoring tool are you using? I'm curious because I've had
>> little luck with tracing the entire process for anything using Dependency
>> Walker's profiling.
>
> http://www.rohitab.com/apimonitor/

I like this tool; I just spent an hour playing with it, and I think it shows
us EXACTLY what is happening.

> Yes, I do think that a ShellExecute probably eventually results in a call
> to CreateProcess, but I'm not convinced that cmd.exe uses ShellExecute
> directly.

I am retracting my earlier suggestion that this is what is happening. Based
on items below, I don't see any reason for the call; it doesn't really save
much. It might happen, but it could just as easily be cmd.exe directly using
the registry expansion and then neglecting to try passing handles to the new
process.

> If I'm reading the API monitor's output correctly, it looks like cmd.exe
> first tries to call CreateProcess with the script file's name, which of
> course fails.

Yep. And if you look at the following extract showing two calls - the first
made calling the script directly, the second invoking it explicitly with
cscript - you can see that bInheritHandles is 0x0 (false) for the
creation-by-name case.

lpApplicationName: "C:\WINDOWS\System32\CScript.exe"
lpCommandLine: ""C:\WINDOWS\System32\CScript.exe" "c:\bin\scripts\rvs.vbs" "
bInheritHandles:0x0

lpApplicationName: "c:\windows\system32\cscript.exe"
lpCommandLine: "cscript rvs.vbs"
bInheritHandles:0x1

It looks like cmd.exe then determines the .js file
> association and calls CreateProcess again with cscript.exe as the
> executable name and the script file as its parameter (which looks correct,
> as far as it goes). I'm not sure where in this process that the input pipe
> gets broken, but I suspect that it's in the second call to CreateProcess.

Yeah - that bInheritHandles:0x0 proves you're right, that it does happen
during the second call. It also confirms that whatever the reason, cmd.exe
itself is explicitly saying to NOT inherit the handles.