0

I'm creating a command line parser and want to support option bundling. However, I'm not sure how to handle ambiguities and conflicts that can arise. Consider the three following cases:

1.

-I accepts a string

"-Iinclude" -> Would be parsed as "-I include"

2.

-I accepts a string
-n accepts an integer

"-Iincluden10" -> Would be parsed as "-I include -n 10" because the 'cluden10' after the first occurrence of 'n' cannot be parsed as an integer.

3.

-I accepts a string
-n accepts an integer
-c accepts a string

"-Iin10clude" -> ??? What now ???

How do I handle the last string? There are multiple ways of parsing it, so do I just throw an error informing the user about the ambiguity or do I choose to parse the string that yields the most, i.e. as "-I i -n 10 -c lude"?

I could not find any detailed conventions online, but personally, I'd flag this as an ambiguity error.

4

1 回答 1

2

据我所知，命令行参数解析没有标准，甚至没有跨平台的共识。所以我们能做的最好的事情就是诉诸常识和最小惊讶原则。

Posix 标准提出了一些解析命令行参数的指导方针。它们只是指导方针；如链接部分所示，一些标准的 shell 实用程序不符合要求。尽管 Gnu 实用程序应符合 Posix 指南，但它们通常在某些方面也存在偏差，包括使用“长”参数。

无论如何，Posix 关于分组的说法是：

当分组在一个“-”分隔符后面时，应接受一个或多个不带选项参数的选项，后跟最多一个带有选项参数的选项。

请注意，Posix 选项都是单字符选项。另请注意，该指南很明确，即仅允许选项组中的最后一个选项成为可能接受参数的选项。

关于 Gnu 风格的长选项，我不知道除了getopt_long实用程序的行为之外的标准。此实用程序为单字符选项实现 Posix 样式，包括上述分组选项语法；它允许带参数的单字符选项紧跟参数，或者位于（可能是单数）选项组的末尾，参数作为后面的单词。

对于长选项，无论选项是否接受参数，都不允许分组。如果选项确实接受参数，则允许使用两种样式：选项后面紧跟一个=，然后是参数，或者参数是后面的单词。

在 Gnu 风格中，长选项不能与单字符选项混淆，因为长选项必须用两个破折号 ( --) 指定。

相比之下，许多基于 TCL/Tk 的实用程序（以及一些其他命令行解析器）允许带有单个 的长选项-，但不允许选项分组。

在所有这些风格中，选项都分为两个不相交的集合：带参数的和不带参数的。

这些系统都不是模棱两可的，尽管您似乎提议的样式的随机混合会是模棱两可的。即使使用正式的消歧规则，歧义也是危险的，尤其是在命令行可能不可逆的控制台应用程序中。此外，如果将来扩展可用选项集，上下文消歧可以（甚至默默地）改变含义，这将是脚本中难以预测的错误的来源。

因此，我建议坚持使用简单的现有实践，例如 Gnu，并且不要太努力地解释不符合要求的错误命令行。

于 2013-06-22T23:27:02.950 回答