Struggle with shell capturing in .NET
-
Hey all! I am building a game server management application, where one of the components needs to capture the output of a console window, and write to it. This can be done using the Process class, but one of the consoles is giving me a hard time.
Instead of just opening a shell which directly accesses the dedicated game server (this is the app which most games have, not my stuff), it opens another shell, and closes the first one. How can I capture and talk to the second, now unreachable shell? This is all within the same process ofcourse.
-
i dunno much about consoles
but i can do
c:\myCommand.com myparam myparam > c:\temp.txt
the output will be in temp.txt
im sure there are other proper ways, but i would use that way because i can't find much examples out there
-
I'm not quite sure what you mean exactly. Is your .Net program a commandline tool starting from a shell window? And does it start a new shell command? Could you explain a bit further?
Drak
-
Yes, I am creating a command application, which calls another shell application, and redirects its in and output. Now, I stumbled upon an awkard app, which creates a new shell (in another window), and closes the initial one. It's like a loader or something. So:
My App > Create and redirect app.exe
App.exe (Window 1) > Create a new window, spawn a shell on there, and close Window 1.
App.exe (Window 2) > The shell I want.Since I've bound to Window 1, I get no response from the application, because that is displayed in another shell.
Hope this clears it up a bit..
-
Well, I don't know a solution to your problem, but I'm 100% sure, that
your app would work on a OS that does not suck, namely any Unix.
SCNR
-
In WIN32, you would do this by setting up some anonimous pipes. One for
the input, one for output and one for the error channel. Then, when
calling the second process, you provide it the handles of these pipes.
You would use the input pipe to write to the second process. The output
and error pipes are used as feedback of what you've been doing.
I think that you should do something similar in .NET but I have absolutely no clue about how to do this...
-
@Katja said:
In WIN32, you would do this by setting up some anonimous pipes. One for
the input, one for output and one for the error channel. Then, when
calling the second process, you provide it the handles of these pipes.
You would use the input pipe to write to the second process. The output
and error pipes are used as feedback of what you've been doing.
That is about the same as it works on Unix, except that on Unix a child
process by default inherits stdout, stdin and stderr (in fact all file
descriptors).
But I assume the command the OP has problems with, does something with similar effect as this:
C:> start anotherprog.exe
Which (in Unix terms) means, that anotherprog gets started on a new
terminal, and hence it does NOT inherit stdin, stdout, stderr. AFAIK
this is the default for Win32 if you just use exec()-equivalent Win32
API. But as you can imagine I do not have much experience with
developing on Win32.
So in other words I think the Problem here is, that on Windows if
another CMD-Window is opened for a child-process, then this is on
another terminal and the stdout/in/err links to the parents process get
lost, and hence your pipes become open ended or even closed. (On Unix
similar problems can arise when using X, but it is always more obvious.)
cu
-
Ok, thanks! I found an article on The Code Project, which uses anonymous pipes to redirect I/O, I'm pretty sure I'll get it to work now. [:)]