How do I call the command line program and get the output and input interaction?

Process has been available for a long time, but I did not pay attention to it.

For example, call a command line: "cmd/c dir c: \ winnt"; put the result in a string.

ProcessStartInfo psi = new ProcessStartInfo ("cmd", "/c dir c: \ winnt ");

Psi. RedirectStandardOutput = true;

Psi. UseShellExecute = false;

Process p = Process. Start (psi );


Output = p. StandardOutput. ReadToEnd ();

P. WaitForExit ();

Note that the waitforexit () must be placed after readtoend. MSDN says this:

The process component communicates with sub-processes through pipelines. If the child process writes too much data to the pipeline to fill the buffer, the child process will be blocked until the parent process reads data from the pipeline. If the application reads all the output to standard errors and standard output, this will lead to a deadlock.

This means: If waitforexit is in the front, if there is too much data beyond the buffer period, the subroutine will wait for the consumer to read the data, but at this time the waitforexit is blocked, as a consumer, the readtoend program cannot be executed, resulting in a deadlock.

In addition to the above, you can also use the program interaction:

ProcessStartInfo psi = new ProcessStartInfo ("cmd ");

Psi. RedirectStandardOutput = true;

Psi. RedirectStandardInput = true;

Psi. UseShellExecute = false;

Process p = Process. Start (psi );


P. StandardInput. WriteLine (@ "dir c: \ winnt ");

P. StandardInput. WriteLine (@ "ver ");

P. StandardInput. WriteLine (@ "exit ");


Output = p. StandardOutput. ReadToEnd ();

P. WaitForExit ();

Redefines stdin, executes the cmd program, enters the command line interaction, and then writes several commands to the standard input. Press enter. This is an interesting execution! In the END, do not forget to use the "exit" command to interrupt cmd execution. Otherwise, the END will never be read during the subsequent readtoend, and the program will not exit again.

Finally, MSDN mentions standarderror. If stdout and stderr are redirected at the same time, a deadlock may occur in an improper way: for example:
String output = p. StandardOutput. ReadToEnd ();

String error = p. StandardError. ReadToEnd ();

P. WaitForExit ();

MSDN says the program reads stdout first and then stderr. If the sub-process writes content to stderr during execution, the deadlock will occur. I thought about it for a while. if the program is written in both streams, can the content of stderror be kept before the first stdout read is completed? But there is no time to try.

MSDN recommends using two threads to process different redirected streams. This is a good solution.