Question

我找到了以下代码片段：

使用System; 使用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);    
    }
}

但我无法弄清楚p.StartInfo.Arguments = "/c dir *.cs";正在做什么？提前感谢任何解释

Answer 1

它将command line arguments传递给将要启动的进程。

在这种特殊情况下，该进程是Windows shell（cmd.exe）。将命令行传递给它将导致它在启动时执行此命令;然后，由于开头的/c参数，它将自行终止。

因此，如果打开命令提示符并输入命令dir *.cs，则该过程的输出将完全相同。

Answer 2

最初是exec(3)及其朋友，它们接受可执行文件的路径和参数指针的可变长度列表。在理智的操作系统中，开始的进程接收到参数列表的一个点，每个单词包含一个指向单个字符串的指针。 Sane shell解析命令行并填充exec（3）所需的参数列表。

您可以看到exec（3）接受的参数列表之间的直接关联：

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

以及传递给流程入口点的内容：

int main（char * arg []）{...}

其中argv[0]是可执行文件名，argv[1] - argv[n-2]是各个参数，argv[n-1]是一个NULL指针，用于指示参数列表的结尾。

概念上既简单又简单。

CP / M没有这样做（我假设因为内存有限）。它从shell中传递了原始命令行的地址，并将其解析为进程。

DOS于1982年作为CP / M的克隆，将原始命令行的地址交给已启动的进程。

Windows从一开始就没有偏离该模型。 Win32 CreateProcess()函数

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

仍然做同样的事情，传递原始命令行传递给程序。当然，C运行时库负责为您解析命令行...或多或少。

所以...在CLR / .Net世界中，由于所有这些历史记录，并且因为CLR被设计为依赖于Win32 API，所以您已经将完整的命令行传递给要启动的进程。为什么他们不允许你通过params string[]而是让CLR构建命令行是微软的开发人员紧紧抓住他们的东西。

构建启动程序所需的命令行很简单。您只需将每个参数连接到一个字符串中，并使用SP字符分隔参数。简单！

...直到你的一个参数包含空格或双引号字符（"）。

然后你必须引用一个或所有的论点。应该很容易，但是由于奇怪的引用规则，有许多边缘条件可能会让你失望。

Windows命令行被分解为由空格分隔的单词，可选择引用双引号（"）。部分原因是Windows的路径分离器错误（\而不是/），引用规则是......拜占庭。如果您深入了解Windows CRT源代码（该文件类似于 {VisualStudioInstallLocation} \ VC \ crt \ src \ stdargv.c），您将找到命令行解析代码。

Answer 3

该行只是为该过程提供了一个参数。

c＃中的StartInfo.Arguments

3 个答案: