使用 .net 从子进程重定向 Stout
我正在使用以下代码
System::Diagnostics::Process^ p = gcnew System::Diagnostics::Process();
p->StartInfo->FileName = "tnccmd.exe";
p->StartInfo->UseShellExecute = false;
p->StartInfo->RedirectStandardInput = true;
p->StartInfo->RedirectStandardOutput = true;
p->Start();
System::IO::StreamWriter^ tnc_stdin = p->StandardInput;
System::IO::StreamReader^ tnc_stdout = p->StandardOutput;
tnc_stdin->WriteLine("connect i 127.0.0.1");
String^ prg_output = tnc_stdout->ReadToEnd();
我的问题是我无法正确读取 stdout 。 不过，我可以轻松地写入 stdin ，但现在我正在尝试实现一些错误检查代码，但它不起作用。
我正在使用的程序似乎没有写入 stdout 即使它是在命令行中运行的。 我可以使用默认情况下随 Windows XP 附带的 ftp.exe 重现该 bug。 如果您使用 ftp.exe 更改 ->FileName，命令提示符 ftp.exe 通常会给出 ftp>不会显示在 prg_output 中。
现在我知道提示符必须使用某种 windows shellcurses 并且我可能会混淆问题。
通常，在 connect i 127.0.0.1 指令之后，我应该收到 connecting to 127.0.0.1... 但我什么也没收到。
关于我做错了什么的任何提示吗？ 是否还有另一种我不知道的 stdout ？
编辑
我无法使用参数，因为我有多行要写，就像 ftp.exe 一样。 此外，当您键入 dir 等命令时，ftp.exe 也会输出。 至少当您编写未知命令时它会输出，它会抱怨无效命令。
I'm using the following code
System::Diagnostics::Process^ p = gcnew System::Diagnostics::Process();
p->StartInfo->FileName = "tnccmd.exe";
p->StartInfo->UseShellExecute = false;
p->StartInfo->RedirectStandardInput = true;
p->StartInfo->RedirectStandardOutput = true;
p->Start();
System::IO::StreamWriter^ tnc_stdin = p->StandardInput;
System::IO::StreamReader^ tnc_stdout = p->StandardOutput;
tnc_stdin->WriteLine("connect i 127.0.0.1");
String^ prg_output = tnc_stdout->ReadToEnd();
My problem is that I cannot read stdout correctly. I can easily write to stdin however, but now I'm trying to implement some error checking code and it doesn't work.
The program I'm using doesn't seem to write to stdout even if it is made to run in command line. I can reproduce the bug with ftp.exe which comes with Windows XP by default. If you change the ->FileName with ftp.exe the command prompt ftp.exe usually gives ftp> will not show up in prg_output.
Now I know that the prompt must use some kind of windows shell curses and I may be mixing up problems.
Normaly just after the connect i 127.0.0.1 instruction I'm supposed to received connecting to 127.0.0.1... but I receive nothing.
Any hint on what I'm doing wrong? Is there another kind of stdout that I'm not aware of?
EDIT
I cannot use arguments because I have multiple lines to write, much like with ftp.exe.
Also, ftp.exe does output when you type commands like dir. At least it outputs when you write unknown commands, it complains about Invalid command.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我怀疑您正在尝试向标准输入发送实际上应该是命令行参数的内容。 您通常如何调用 tnccmd.exe？ 像这样的东西吗？
如果是这种情况，那么“connect i 127.0.0.1”不应该在标准输入上继续，而应该通过 p->StartInfo->Arguments 传递。
（ftp.exe 的问题不在于您的程序，而在于 ftp.exe 本身，它会查找其标准输出是否是控制台。如果其输出不在控制台上，则它不会输出“ftp>”提示。您尝试编写的程序也可能执行相同的操作。）
I suspect that you're trying to send to stdin what should actually be a command-line argument. How would you normally invoke tnccmd.exe? Something like this?
If that's the case, then "connect i 127.0.0.1" shouldn't go on stdin, but should be passed via p->StartInfo->Arguments.
(The problem with ftp.exe isn't with your program, but rather ftp.exe itself, which finds out if its stdout is the console. If its output is not on the console, then it does not output the "ftp>" prompt. It's also possible that the program you're trying to script does the same thing.)
也许是缓冲的问题。
如果您尝试刷新 tnc_stdin 会发生什么？
尝试这样的事情：
编辑：检查您正在使用的 StreamWriter 的 ctor（反射器规则！）
根据它，默认缓冲区大小是 1024 字节...所以你需要刷新:-)
或者您可以定义一个较小的缓冲区。
maybe it is an issue with buffering.
What happens if you try to flush tnc_stdin ?
try something like this:
Edit: Checked the ctor of StreamWriter that you are using(Reflector rules!)
According to it, the default buffer size is 1024 bytes... so you need to flush :-)
or you can define a smaller buffer.
我认为您忘记调用 BeginOutputReadLine
I think that you forgot to call BeginOutputReadLine
请参阅这篇关于从托管应用程序捕获标准输出和错误的博客文章。 CLR 使得很容易做错事并陷入僵局。
如何正确使用 System.Diagnostics.Process
See this blog post about capturing both standard Out and Err from managed applications. The CLR makes is very easy to do the wrong thing and deadlock yourself.
How to use System.Diagnostics.Process correctly