在程序里调用命令行程序

<script>function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}</script> 在程序里调用命令行程序，一位cnblog的仁兄写的

process早就有办法了, 只不过我没有注意.

如调用一个命令行:"cmd /c dir c:\winnt"; 把结果放到一个字符串里.

ProcessStartInfopsi=newProcessStartInfo("cmd","/cdirc:\winnt");
psi.RedirectStandardOutput=true;
psi.UseShellExecute=false;
Processp=Process.Start(psi);

output=p.StandardOutput.ReadToEnd();
p.WaitForExit();

注意那个waitforexit()一定要放到readtoend之后. MSDN里这样说:

process组件通过管道与子进程通信。如果子进程写入管道的数据多得足以填满缓冲区，则子进程将一直会阻塞到父进程从管道读取数据时为止。如果应用程序将所有输出读取到标准错误和标准输出，则这会导致死锁。

意思就是: 如果waitforexit在前, 那么如果数据太多而超出缓冲期大小, 子程序就会等着消费者把数据读出来, 可是这时候由于waitforexit正在阻塞, 做为消费者的过程序readtoend无法执行, 因而导致了死锁.

除了上面的, 还可以用程序交互:

ProcessStartInfopsi=newProcessStartInfo("cmd");
psi.RedirectStandardOutput=true;
psi.RedirectStandardInput=true;
psi.UseShellExecute=false;
Processp=Process.Start(psi);

p.StandardInput.WriteLine(@"dirc:\winnt");
p.StandardInput.WriteLine(@"ver");
p.StandardInput.WriteLine(@"exit");

output=p.StandardOutput.ReadToEnd();
p.WaitForExit();

重定义了stdin, 执行cmd程序, 进入了命令行交互, 然后向标准输入里写若干个命令, 回车, 有意思, 执行了! 最后千万别忘记了用"exit"命令中断cmd的执行, 不然后面的readtoend时, 永远也不会读到END, 程序又阻塞在这里不会退出.


最后, MSDN提到了standarderror, 如果同时重定向了stdout和stderr, 那么不当的方式也会出现死锁: 如:

stringoutput=p.StandardOutput.ReadToEnd();
stringerror=p.StandardError.ReadToEnd();
p.WaitForExit();

MSDN说程序先读了stdout, 完了之后再读stderr, 如果子进程在执行时向stderr写了内容, 那么就会死锁. 我想了一会儿, 没想明白. 如果程序在两个流里都写入了, 那么第一个读stdout的动作完成之前, stderror的内容留着不就行了? 但是没有时间试了.
MSDN建议用两个线程来处理不同重定向流. 这是个好办法.