Thanks for the info. This is good to know. However, afaict, this will not work in a general sense as you would have to "know" all native commands before hand to make a generic console UI in Form. Seems there is more edge cases here then at first glance. Why things like edit.com still don't work under msh? Seems like interactive programs could work in all cases if: 1) All output was redirected to pipeline. 2) Have two input streams. A raw keyboard input stream (for things like More prompt and special keys) and a std input data stream.
Or maybe 1 input Q and 1 output Q and everything is a Message and handled based on Message type.
Console2...Console2...Console2. I guess I have to punt. Cheers Marcel.
-- William Stacey [MVP]
"Marcel Ortiz [MSFT]" <mos...@microsoft.com> wrote in message news:%23tPWftQWGHA.4972@TK2MSFTNGP02.phx.gbl... | Unfortunately the pipeline APIs don't provide a way of saying, "run this and | always redirect native executables". At this point its pretty much a | heuristic that determines whether or not the pipeline gets redirected. | Like, /\/\o\/\/ mentioned, the pipelines aren't always redirected because we | need interactive applications to work correctly. You'll notice that if a | native application is the only command in a pipeline then the output isn't | redirected. If it's assigned to something on the other hand (like $a = ping | localhost) then the output is redirected. Also, if the output of the | command is redirected into another command, then the output is also | redirected. For example, run "ping localhost | foreach { write-host "foo | $_" }". In any case, it sounds like a switch on the pipeline APIs that | always forces redirection of native executables would be useful. Its been | discussed, though I don't think it has too high a priority at this point. | You might want to open a bug. In the meantime, let me offer you a | workaround: | | string command = "ping localhost"; | | command = string.Format("$results = . {{ {0} }}; $results", command); | | Pipeline p = r.CreatePipeline(command); | | | | This will force redirection because the results are being assigned to a | variable. It does have one large downside and its that because the results | are assigned to a variable and then the results of the variable are output, | you won't get any results until all the execution is complete. | | -- | Marcel Ortiz [MSFT] | Monad: Microsoft Command Shell | Microsoft Corporation | This posting is provided "AS IS" with no warranties, and confers no rights. | | | "William Stacey [MVP]" <william.sta...@gmail.com> wrote in message | news:OQ1jw9OWGHA.5012@TK2MSFTNGP05.phx.gbl... | > TMK, if we had Console.Out redirected, it would work. However, we don't | > even have a console attached because we have a win program. So Ping | > starts | > a new console and writes to that AFAICT. So do we have to start a hidden | > console just so that we have a console attached to the process and also | > read | > from it in addition to the pipeline?? This would seem all very messy. | > MS...what say you? | > | > -- | > William Stacey [MVP] | > | > "TonyDeSweet" <shenzhong...@gmail.com> wrote in message | > news:1144265391.126685.232490@u72g2000cwu.googlegroups.com... | > |I have tried that. It is NOT Working. | > | Legacy program (like ping) still writes directly to Console.Out | > | | > | > | |
But, It is still a problem. As William Stacey mentioned, How do you know in advance that next user input is a "native executables".
For a non-interactive "native executables" like ping.exe, it is OK if we just lost some output. What if an interactive "native executables" want's to read from Console.In and MshHost did not redirect Console.In, Host would wait "native executables" to exit and freeze for a long time( until timeout). This will cause big problem.
Good job, William! I am going to explore your code tonight. I am moving away from console windows altogether. However, this raises another problem: when you launch an app from MSH that requires a console such as NETSH or WMIC, it will break.
To further complicate matters, there are external console apps that require access to stdin. So even though ping does redirect using the tricks mentioned before, commands like "netsh" and "wmic" fail. They only work if I AllocConsole a console window and type the desired input "blindly" into the blank console window. The result again is redirected correctly.
I did not find a way to provide a redirected stdin so far that would work with such commands.
I tend to agree that MSH development is a bit too console-centric. After all, we are all more or less trying to escape the console. I'd love to see some general "console wrapper".
Does anyone know when there will be a more comprehensive SDK for MSH? I found some bits but without the meat I was looking for... ;-)
> But, It is still a problem. As William Stacey mentioned, How do you > know in advance > that next user input is a "native executables".
> For a non-interactive "native executables" like ping.exe, it is OK if > we just lost some output. What if an interactive "native executables" > want's to read from Console.In and MshHost did not redirect > Console.In, Host would wait "native executables" to exit and freeze for > a long time( until timeout). This will cause big problem.
Unfortunately yes. I don't know the solution here. I guess you could also start a hidden console and capture that, but that seems hacky, plus not sure even that will handle all cases. I can't seem to find the light on these issues.
-- William Stacey [MVP]
"Tobias Weltner [MVP]" <tobweltnerAThotmail.com> wrote in message news:uLRPPFLXGHA.1348@TK2MSFTNGP05.phx.gbl... | Good job, William! | I am going to explore your code tonight. | I am moving away from console windows altogether. | However, this raises another problem: when you launch an app from MSH that | requires a console such as NETSH or WMIC, it will break. | |
I think the general issue is the two win32 api modes of the console - high-level and low-level. One needs to address both to get all apps working or you can loose output or hang waiting for input that never comes. Question is how to do this cleanly?
-- William Stacey [MVP]
"Tobias Weltner [MVP]" <tobweltnerAThotmail.com> wrote in message news:%230UyvKLXGHA.4144@TK2MSFTNGP04.phx.gbl... | To further complicate matters, there are external console apps that require | access to stdin. So even though ping does redirect using the tricks | mentioned before, commands like "netsh" and "wmic" fail. | They only work if I AllocConsole a console window and type the desired input | "blindly" into the blank console window. The result again is redirected | correctly. | | I did not find a way to provide a redirected stdin so far that would work | with such commands. | | I tend to agree that MSH development is a bit too console-centric. After | all, we are all more or less trying to escape the console. I'd love to see | some general "console wrapper". | | Does anyone know when there will be a more comprehensive SDK for MSH? I | found some bits but without the meat I was looking for... ;-) |
|
