我很好奇是否有任何广泛的概述，最好是关于GNU样式的规范/技术报告以及解析命令行参数的其他常用样式。
据我所知，有很多捕获，编写一个与C ++ boost :: program_options，Python的argparse，GNU getopt等一样兼容的解析库并不是一件容易的事。
另一方面，可能有些图书馆在接受某些选项时过于自由，或者过于严格。因此，如果一个人想要与事实上的标准（如果存在的话）具有良好的兼容性/一致性，那么有没有比简单地阅读一些成熟的库源代码更好的方法和/或测试用例？
答案 0 :(得分：2)
Posix提供了实用程序语法的指南，如XBD Chapter 12（基本定义）。这当然值得一读。如上所述，向后兼容性意味着许多标准化实用程序不符合这些准则，但标准建议
...所有未来的实用程序和应用程序都使用这些指南来增强用户可移植性。一些历史实用程序无法更改（以避免破坏现有应用程序）的事实不应该阻止这个未来的目标。
您还可以阅读rationale了解语法指南。
Posix提供了一个基本语法，但它对于具有大量参数的实用程序来说是不够的，而单字母选项在自我文档中有些缺乏。一些实用程序 - test，find和tcpdump让人想起 - 基本上实现了特定于域的语言。其他人 - 例如ls和ps - 有一个令人眼花缭乱的调用选项。更不用说编译器......
多年来，已经考虑了许多可能的扩展方法，并且可能所有这些方法仍然在至少一个常见（甚至可能是标准的）实用程序中使用。 Posix建议使用-W作为扩展机制，但很少使用它。 X Windows和TCL / Tk推广使用拼写的多字符选项，但这些实用程序期望长选项名称仍然以单个破折号开始，这使得无法压缩非参数选项[注1]。其他实用程序 - dd，make和awk，仅举几例 - 具有{íd}={val}形式且没有连字符的特殊情况参数。使用双连字符的GNU方法似乎在很大程度上赢了，部分原因是因为这个原因，但GNU风格的选项重新排序并没有得到普遍认可。
在GNU style guide中可以找到关于GNU风格的简短讨论（另请参阅list of long options），在Eric Raymond的The Art of Unix Programming [注2]中稍微简短的讨论。
Google代码将命令行选项提升到新的水平;内部库现在已经开源为gflags所以我认为现在没有违反保密性来观察Google的服务器管理工具有多少是通过命令行选项完成的。 Google标志在整个代码中不加区别地分散，因此库函数可以定义自己的选项，而调用程序无需了解它们，从而可以独立于应用程序定制关键库的行为。 （也可以在运行时动态修改gflag的值，这是另一个有用的服务管理工具。）从语法的角度来看，gflags允许单连续和双连字符长选项表示，不加选择地和它不允许合并的单字符选项调用。 [注3]
值得强调的是 Unix编程环境（Kernighan＆amp; Pike）中的观察，因为shell“必须满足命令执行的交互和编程方面，它是一种奇怪的语言，形状历史和设计一样多。“这两个方面的要求 - 简洁的交互式语言和精确的编程语言的愿望 - 并不总是兼容。
语法灵活性虽然对交互式用户很方便，但对于脚本作者来说可能是灾难性的。例如，我昨晚输入-env=...而不是--env=...，这导致我将nv=...传递给-e选项，而不是将...传递给--env 1}}选项，直到有人问我为什么我将那个奇数字符串作为EOF指标传递时才注意到。另一方面，我的宠物虫 - 事实上有些人更喜欢--long-option而其他人更喜欢--long_option，有时你会在同一个程序中找到这两种风格（我在看着你，{{3} }） - 作为交互式用户和脚本编写者同样令人讨厌。
可悲的是，我不知道有任何资源可以作为这个问题的答案，我也不确定上述内容是否满足需要。但也许我们可以随着时间的推移改进它。
备注：
显然这是个坏主意，因为构建有用的netstat调用的消遣是不可能的，其参数是一个可读的词。
本书及其作者分别称为TAOUP和ESR。
我花了一段时间才习惯这个，而且很少有时间恢复我的旧习惯。所以你可以看到我的偏见所在。