Question

I found the following snippet of the code:

using System;
using System.Diagnostics;

public class RedirectingProcessOutput
{
    public static void Main()
    {
        Process p = new Process();
        p.StartInfo.FileName = "cmd.exe";
        p.StartInfo.Arguments = "/c dir *.cs";
        p.StartInfo.UseShellExecute = false;
        p.StartInfo.RedirectStandardOutput = true;
        p.Start();

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

        Console.WriteLine("Output:");
        Console.WriteLine(output);    
    }
}

but I can’t figure out what this p.StartInfo.Arguments = "/c dir *.cs"; is doing? thanks in advance for any explanation

Answer 1

In the beginning was exec(3) and its friends, which accept the path to an executable and a variable length list of pointers to arguments. In sane operating systems, The process that gets started receives a point to the argument list, each word of which contains a pointer to and individual string. Sane shells parse the command line and populate the argument list required by exec(3).

You can see a direct correlation between the argument list accepted by exec(3):

exec ("some.executable.file", "arg1" , "arg2" , "arg3" , ... ) ;

and what gets passed to the entrypoint of the process:

int main ( char *arg[] ) { … }

where argv[0] is the executable name, and argv[1]—argv[n-2] are the individual arguments, and argv[n-1] is a NULL pointer to indicate the end of the argument list.

Both conceptually simple and simple to implement.

CP/M didn’t do it that way (I assume because of limited memory). It passed the started process the address of the raw command line from the shell and left its parsing up the process.

DOS followed in 1982 as clone of CP/M, handing a started process the address of the raw command line as well.

Windows hasn’t deviated from that model since its inception. The Win32 CreateProcess() function

BOOL WINAPI CreateProcess(
  __in_opt     LPCTSTR lpApplicationName,
  __inout_opt  LPTSTR lpCommandLine,
  ...
);

still does the same thing, passing the raw command line to be passed to the program. The C runtime library, of course, takes care of the command line parsing for you…more or less.

So…in the CLR/.Net world, because of all this history, and because the CLR was designed to be dependent on the Win32 APIs, you have pass a complete command line to the process to be started. Why they didn’t let you pass a params string[], instead and have the CLR build the command line is something that Microsoft’s developers kept close to their chest.

Building the command line required by the started program is simple. You just join each argument into a single string with an SP character separating the arguments. Easy!

…until one of your arguments contains whitespace or a double quote character (").

Then you have to quote one or all of the arguments. Should be easy, but due to the bizarre quote rules, there are a lot of edge conditions that can trip you up.

A Windows command-line is broken up into words separated by whitespace, optionally quoted with double-quoted ("). Partly because Windows also got the path separater wrong (\ rather than /), the quoting rules are…byzantine. If you dig into the Windows CRT source code (the file is something like {VisualStudioInstallLocation}\VC\crt\src\stdargv.c), you’ll find the command line parsing code.