☰

为什么某些实用程序在选项之前解析操作数？

tag-icon • tag-icon utilities options getopts conventions
为什么某些实用程序在选项之前解析操作数？

根据一些 来源，UNIX 实用程序指南指定操作数应始终在选项之后处理：

utility_name[OPTIONS][operands...]

众所周知，一些较旧的 UNIX 实用程序并不完全遵循这些约定，例如，，find但较新且完善的实用程序也违反了规则，而没有明显的解释，例如，curl <url>。

我想知道这是否有充分的理由以及社区对此的普遍共识是什么。

答案1

通常的约定是参数总是跟在选项后面。第一个非选项（命令行上第一个不以 开头的字符串-）终止选项并开始参数。

一些工具，特别是构建工具（编译器、链接器），总是违反这一约定。您注意到的另一个例子是find.有时这样做是因为选项在命令行上出现的位置生效，因此您需要一种在选项之前和之后指定参数的方法，其中仅当参数出现在选项之后时，选项才适用于该参数。

此约定允许您编写包含如下行的 shell 脚本：

rm foobar ${more_things_to_remove}

...并保证rm即使 shell 变量more_things_to_remove具有像“”这样令人讨厌的值，您也不会意外地向命令添加选项-rf。

该约定早于最近使用特殊选项--终止选项处理的约定。--是明确标记选项结尾的更好方法：

rm -- foobar ${more_things_to_remove}

# and it works even if you don't need to delete something called "foobar":
rm -- ${more_things_to_remove}

因此，最近（并且最近，我的意思是这已经持续了很多很多年）更多的命令行解析器似乎正在朝着打破早期约定并允许选项和参数明显地在任何地方混合的方向发展（始终受制于--强制结束选项）即使它们没有任何特殊原因像编译器和其他一些工具那样打破约定。

就我个人而言，我永远不知道哪些实用程序仍然遵守约定，哪些不遵守约定，所以我总是像以前一样在参数之前放置选项，当我看到其他人的工作代码以相反的顺序执行它时，我有点惊讶！

相关内容