在 FreeBSD 和 macOS 上的 getopt(3) 中，它指出（强调我的）：
也可以将数字作为选项字母处理。 这允许
与需要数字 (getopt()) 作为选项的程序一起使用。 这种做法是错误的，不应该在当前的任何开发中使用。 提供它只是为了向后兼容。"-3"
但是为什么是错误的？ 两个手册页都提供了一些示例代码，但我不明白他们想要做什么。 我不明白为什么使用数字作为命令行选项需要任何特殊处理。
Linux' 和 GNU 的 getopt(3) 都没有提到数字作为选项字母，也没有说它们是错误的。那么为什么数字作为选项在 FreeBSD 和 macOS 上据称是错误的呢？
我见过一些程序，例如但是在一定程度上它是错误的，那是因为 BSD 手册页的作者说它是错误的。 这可能反映了 BSD 开发人员的普遍观点，但我很难在 BSD 文档中找到比您已经看到的内容更权威的内容。为什么是错的？
特别注意
POSIX 似乎非常适合使用数字作为选项名称。 关于如何选择选项名称的几乎所有内容都是：
每个选项名称应该是可移植字符集中的单个字母数字字符（这包括小数位，没有任何警告。alnum字符分类）。
两个手册页都提供了一些示例代码，但我不明白他们想要做什么。请注意，它实际上只是
一个手册页。 MacOS 是 BSD 的衍生版本，您链接的 Apple 手册页只是 BSD 页面的重新设计。
无论如何，该示例代码似乎试图使用getopt()
来识别由
-字符组成的程序参数，后跟可能的许多十进制数字，将single 数字表示为一个统一选项。 这确实很糟糕，而且支持它确实违反了 POSIX 准则，我不推荐它。但对我来说，这似乎也是“不合逻辑的”。 我不明白为什么使用数字作为命令行选项需要任何特殊处理。
从编程的角度来看，只要它们仅被视为单独的数字，它们就不会。 然而，当两个或多个十进制数字选项组合在一起时，这确实有可能使程序的“用户”感到困惑。 我认为这是 BSD 手册页热门且令人烦恼的问题，但从那里到个位数选项“错误”对我来说太大了。