2

我正在对接受命令行选项的程序进行一些维护。有单字母选项和长选项。目前，长选项有一个前面的连字符。

许多工具的长选项都有双连字符。为了与现有内容保持一致，我查看了一些 GNU 工具，发现对于长格式，单连字符和双连字符混合在一起。例如，GCC 编译器有--help,--version与-std, -funroll-loops。

所以我搜索了一些关于此事的文档，并找到了这个 GNU 文档。在那里，GNU 对长选项的风格建议是以两个连字符开头。

现在，我想知道为什么 GNU 工具不遵循这些 GNU 建议？我认为这是向后兼容的问题，但还有更多吗？

在我编写的程序中，在更改选项语法时，我通常会保留旧形式的功能但未记录，或者至少给出弃用警告。GCC（和其他）程序不能这样做吗？

4

2 回答 2

2

There are plenty of reasons not to change:

  • There are quite literally millions (probably many more?) of configuration scripts and build files that use the existing command line options. Both recent and very old.
  • People are used to the current format so most programmers for many years will just use what they already know out of habit.
  • Argument parsing code is often complicated and changing it is just another opportunity for introducing bugs.
  • The old backward compatibility single hyphen long options would conflict with the new multiple short options combined so backwards compatibility is difficult.
  • Insert many more here.

Reasons to change:

  • To follow convention that is already not followed by many applications.

In short convention is nice and should ideally be followed for new stuff but often it is not worth changing stuff just for the sake of conformity.

于 2012-12-16T08:22:48.310 回答
0

Makefile 和其他构建脚本通常（至少部分地）编写与编译器无关，因此 GNU C 编译器（以及扩展的 GNU 编译器集合gcc）必须在调用方式上与其他编译器保持兼容。一些 C 编译器肯定早于 GNU 程序参数语法约定。其他与开发相关的命令也是如此ld，ar例如 等，尤其是 UNIX 标准的那些部分。

某些命令中的“传统”语法甚至可能需要遵守某些标准。（C 和 C++ 标准似乎只指定了编程语言，但我可以想象 UNIX 标准也涵盖了某些开发工具的命令行参数。）

于 2015-02-26T22:36:22.863 回答