StartInfo.c#中的参数

本文关键字:参数 StartInfo | 更新日期: 2023-09-27 18:08:55

我找到了下面的代码片段:

使用系统;使用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";在做什么?提前感谢您的解释

StartInfo.c#中的参数

将命令行参数传递给将要启动的进程。

在本例中,进程是Windows shell (cmd.exe)。向它传递命令行将导致它在启动时执行此命令;然后,由于开头的/c参数,它将自行终止。

因此,如果您打开命令提示符并输入命令dir *.cs,那么该过程的输出将完全是您将得到的。

开始是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),您将找到命令行解析代码。

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