为何BSD与macOS的getopt(3)将数字作为选项视为错误用法？

FreeBSD和macOS的getopt(3)手册明确标注：

也可以将数字当作选项字母处理，这允许getopt()用于接受数字（如"-3"）作为选项的程序。这种做法是错误的，不应在当前任何开发中使用，仅为向后兼容而提供。

数字作为选项的冲突根源 #

• 违背命令行语义直觉：命令行中数字通常是位置参数（如文件数量、数值参数）或选项的参数值（如-n 10里的10）。将数字直接作为选项（如-3）会打破用户认知，引发歧义——比如program -3 file.txt，用户无法直观判断是指定选项3，还是给某个选项传参数3。
• 解析逻辑存在歧义：BSD系getopt的解析逻辑会绑定选项与参数，遇到-x3这类输入时，无法明确是把3当作-x的参数，还是独立选项3，导致解析行为不可预期，增加程序出错概率。
• 不符合POSIX隐含约定：POSIX规范中，命令行选项默认仅包含字母字符，数字并未被纳入标准选项范畴。BSD系getopt严格遵循这一约定，因此将数字作为选项被标记为错误用法，仅为兼容老旧程序保留。

为什么GNU/Linux的getopt无此限制？ #

GNU的getopt实现做了非标准扩展：它通过--明确分隔选项与位置参数，同时对数字选项的解析逻辑做了特殊处理，避免歧义。但这是GNU专属特性，并非所有系统都支持。

实际使用中的特例（如gzip） #

像gzip -3这类程序能正常工作，要么是使用了GNU的getopt实现，要么是在BSD系系统中特意做了兼容处理，但这属于历史遗留特例，不推荐新开发效仿——会降低程序跨平台兼容性，也不符合现代命令行设计规范。

内容的提问来源于stack exchange，提问作者Paul J. Lucas