0

为什么 Windows 程序会从可执行文件的路径中解析命令行开关？（后者就是通常所说的argv[0]。）

例如，xcopy：

C:\Temp\foo>c:/windows/system32/xcopy.exe /f /r /i /d /y * ..\bar\
Invalid number of parameters

C:\Temp\foo>c:\windows\system32\xcopy.exe /f /r /i /d /y * ..\bar\
C:\Temp\foo\blah -> C:\Temp\bar\blah
1 File(s) copied

我应该在自己的程序中遵循什么行为？

是否有许多用户希望键入没有空格的命令行开关（例如，program/?而不是program /?），我应该尝试支持这一点，还是应该只报告错误并立即退出？

我还需要注意哪些其他警告？（除了 Anon. 在下面的评论之外，即使“debug\program.exe”存在，“debug/program”也会从 PATH 运行 debug.exe。）

4

3 回答 3

2

我认为实际上是 DOS shell 这样做：

我的理解是 DOS 选择使用正斜杠 (/) 作为命令行选项（即“DIR /s”），甚至在 DOS 支持 sub-directories 之前。后来，当他们引入子目录时，他们意识到他们不能使用正斜杠作为路径分隔符（UNIX 上的标准），所以他们不得不使用反斜杠。

还有一个因素是 DOS 在命令名和第一个参数之间不需要空格。（即，“CD\”与“CD\”相同。）

由于上述原因，我的猜测是不是程序“错误地”解析命令行 - 而是使用“C：”作为可执行文件/命令名称的DOS shell，其余为命令行参数。（当然，一个经过测试的应用程序可以验证这一点，但我现在远离我的编译器。）

于 2010-02-26T01:02:47.617 回答
0

我希望任何执行此操作的程序都将使用GetCommandLine()而不是argv[]访问命令行参数，并且无法考虑 Windows 上用户模式路径的可替代性/和\在用户模式路径中的可替代性。

于 2010-02-26T01:01:06.770 回答
0

我有几个建议可能会有所帮助。这些是我制作（和使用）的一个类的结果，它只是为了处理参数和开关。

  • 我检查参数数组以查看哪个分隔符用于路径以及哪个分隔符用于开关/参数。

  • 我个人使用斜杠和连字符来区分开关和参数。

  • 如果传递的开关与任何预期的参数或开关都不匹配，我会检查是否仅使用一个斜杠传递了多个开关。如果用户输错了某些内容，这已经导致并将给用户带来更多问题。例如，如果我正在寻找 /d /e /l -or- /del SomeThing 并且用户输入 /del 以传递 de 和 l 开关。

  • 在该对象中，我将开关填充在一个 std:: 容器中，并将参数和参数值填充在另一个 std:: 容器中，然后消费者应用程序可以在它认为合适的时候对其进行处理。

于 2010-02-26T05:24:09.663 回答