我应该如何解析捆绑的命令行选项和歧义？

Question

我正在创建一个命令行解析器，并希望支持选项捆绑。但是，我不确定如何处理可能出现的歧义和冲突。请考虑以下三种情况：

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 ??? 

如何处理最后一个字符串？有分析它的多种方式，所以我只是把一个错误，通知用户有关歧义或做我选择解析产生最，即作为字符串“-I我-n 10 -c路得”？

我找不到任何详细的约定网上，但个人，我会将此作为一个多义性错误。

Answer 1

据我所知，对命令行参数解析没有标准，甚至也不是一个跨平台的共识。所以我们能做的最好的是吸引常识和principle of least astonishment。

POSIX标准提出了一些guidelines用于解析命令行参数。他们只是指导方针;如链接部分所示，某些标准shell实用程序不符合。虽然Gnu公用事业公司预计符合Posix指南，但它们在某些方面通常也会有偏差，包括使用“长”参数。

在任何情况下，什么样的Posix说，关于分组是：

没有选项参数

一个或多个选项，然后在最多一个选项接受一个选项参数，当后面一个分组应该被接受' - '分隔符。

注意，Posix的选项都是单字符选项。还要注意，准则明确指出，只有选项组中的最后一个选项才被允许作为可能接受参数的选项。

对于GNU风格的长选项，我不知道比getopt_long实用程序的行为之外的标准的。此实用程序为单个字符选项实现Posix样式，包括上述分组选项语法;它允许的接受参数要么紧跟参数，或者是在一个（可能是单数）选项组用参数如下面的单词的末尾单个字符选项。

对于长时间选项，分组是不允许的，不管选择是否接受参数。如果选项不接受参数，两种风格的允许：要么选项紧跟着的一个=，然后论证，或参数为以下字。

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

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

在所有的这些款式，选项分为两个不相交集：那些带参数的，和那些没有。

这些系统都不是模糊的，虽然款式随机搭配，你似乎可以提出，将是。即使有正式的消歧规则，模糊也是危险的，特别是在命令行不可逆的控制台应用程序中。此外，语境消歧可以（甚至默默）变化的意义，如果一套可用的选项是在未来，这将是脚本难以预测错误的根源延长。

因此，我建议坚持一个简单的现行做法比如GNU，并且不尝试太难解释不符合不正确的命令行。