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";
在做什么?提前感谢您的解释
将命令行参数传递给将要启动的进程。
在本例中,进程是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),您将找到命令行解析代码。
这一行只是为该进程提供了一个参数。