每个 CLI 命令选项都是语义缩写吗

每个 CLI 命令选项都是语义缩写吗

关键在于语义。

curl -I,这意味着curl --head,让我困惑。I我不知道字母表代表什么语义?它只是一个参考而不是语义词的缩写吗?同样curl -b,这意味着curl --cookie,有同样困惑的问题。

有人能说清楚发明者最初是如何进行这样的设计的吗?上面的例子是否意味着选项不必是语义的?

答案1

乍一看,我似乎无法回答这个问题,只能说,不,选项似乎总能发现无意义的。您可以制作自己的程序,故意使用完全毫无意义的命名选项。 (当然,即使如此,如果它们被故意选择为无意义,你也可能会说它们在无意义中有意义。)

然而,经过进一步考虑,我意识到选项语义的模糊性实际上是命令行选项命名方式的一个重要且有用的部分,并且curl -I是一个特别说明性的例子。

正如穆鲁所说, 选项没有具有语义性。但是curl-I选择语义。卷曲(1)

-i/--include
        (HTTP) 在输出中包含 HTTP 标头。 HTTP 标头包括服务器名称、文档日期、HTTP 版本等内容...

-I/--head
       (HTTP/FTP/FILE) 仅获取 HTTP 标头! HTTP 服务器具有 HEAD 命令,该命令只获取文档的标题。当用于 FTP 或 FILE 文件时,curl 仅显示文件大小和上次修改时间。

-i是 的缩写形式--include,导致包含 HTTP 标头。虽然-I是 的缩写形式--head,但它在语义上是更强的形式-i,同时-i给你 HTTP 标头,-I给你仅有的HTTP 标头。

这提供了对您更大问题的洞察:有许多不同的标准可以用来判断选项名称是否是语义的。当一个选项语义上它可能是有意的或无意的。如果您只关心是否存在一些记住这个选项就像它是语义的一样,那么是的,你总是可以编造一个与它的含义相关的名称的原因。

有些选项具有不止一种语义。你可以制作GNUgrep显示与-Afor匹配的行相邻的行-B为了,并且-C对于语境这给了你们两个。因此, -A/ --after-context-B/--before-context-C/三个选项的缩写形式--context在含义上非常接近,在字母表中也彼此接近。这是语义吗?

要进一步追求这一点并获得严格的答案,您可以搜索适用的标准,例如POSIX.1-2008。它禁止无意义的命名选项,这似乎非常难以置信,但我想你必须仔细阅读整件事才能确定。粗略的搜索并没有揭示出选项有任何意义的任何要求。尤其,这些官方指南--仅对于其文档声明符合它们的命令是必需的--建议对选项的命名方式以及传递它们的效果进行各种限制,但它们没有提及任何可以解释为选项名称提出的要求或建议的内容感觉。即使您确实找到了一些东西,许多类 Unix 系统的目标并不是完全符合 POSIX...

但整个思路——咨询官方消息来源以确定(供应商必须假装)每个选项的名称是否有意义——有点愚蠢。了解选项真正有用的是它们的名称可以通过多种方式相互关联。它们可以根据单词、其他选项或按字母顺序与其他选项相邻来命名。有时它们只是碰巧可用的字母(或数字)。思考这些方法可以帮助您记住选项,在搜索手册页时找到选项,并就您自己的脚本或程序应采用的选项名称做出正确的决定。

最后一点,最好记住这不仅仅是简写选项的命名方式不允许您推断其含义。例如,长格式选项--regex--regexpmlocate从语义上命名,因为它们都与正则表达式有关。但它们的命名方式并没有告诉你这--regexp意味着下一个参数是一个布雷--regex意味着全部模式参数是埃雷s。

相关内容