アレッ*_*ックス 5 terminal console arguments
为什么控制台应用程序以以下任一方式开始参数：
a) one dash (myapp -arg1 123; ls -al)
b) two dashes (myapp --arg1 123; git push origin master --force)
c) without dashes at all (myapp 123; man ls)
d) without dashes but with the equal sign (myapp arg1=123; dd if=/dev/zero)
没有标准的约定吗？即使在标准 Linux 应用程序中，a)、b) 和 d) 三种情况确实同时存在。并且很难记住我应该何时使用，例如，-help 以及何时使用 --help。
Bar*_*mar 13
破折号用于表示选项，它修改命令的行为。没有破折号的参数表示命令的主要参数，通常是文件名。
单个连字符通常引入仅由一个字母组成的选项。多个此类选项可以组合在一起，因此ls -a -l可以缩写为ls -al. 这是大多数早期 Unix 命令的标准约定。
双连字符引入了整个单词的选项。该约定对于将它们与上述分组区分开来是必要的。这种选项风格因 GNU 版本的实用程序而流行，因为它们通常具有太多的功能，以至于用完助记符的单个字母。
有时一个选项需要它自己的参数。其样式各不相同：有些命令使用-o parameter，有些使用-oparameter，有些使用--option=parameter，有些允许多种形式。
还有一些命令发明了它们自己的异质论证风格。这些通常是非常古老的命令，在对参数约定达成共识之前。这方面的例子是tar和dd。find在--创建约定之前使用完整单词选项的旧命令也很不寻常；它的论点实际上是它自己的一种语言，因为它的需求不符合典型的command -options parameters范式。
命令之间变化的其他原因是 Unix 最初没有参数解析库函数。直到其生命周期中的getopt和getopts函数才被创建。使用这些库本质上会迫使您遵循常见的做法。但是较旧的程序会进行自己的临时参数解析，并且不同的程序员会做出不同的决定。
@Barmar 是正确的，但缺少一些信息。为什么会发生这种情况完全是因为程序代码是如何编写的，更具体地说，是因为用于解析参数的内容。
在我谈论更多之前，我想澄清一些术语。首先，你所说的“选项”实际上也是参数。事实上，您在命令行上输入的所有内容都是一个参数（包括程序名称）。这些参数通常存储在一个数组中（argv在 C 中调用）。然后，程序选择如何（或是否）解析这些参数并做出相应的行为。现在，参数通常采用以下三种形式之一：
1并且2通常被称为OPTIONS和 旨在改变程序行为，但两者都以不同的风格出现（Barmar 也提到过）。C 的getopt库实际上在这方面提供了很大的灵活性。尽管约定是将选项指定为单个连字符前面的单个字母或两个连字符前面的完整单词，但编写的程序getopt实际上允许以下任何一个等效（假设作为索引help给出h)：
-h,--h,--help
然而，-help实际上是不允许的getopt（所以，如果一个工具使用-help了它的使用标志，那么你可以很确定它不是用getopt库编写的）。这是因为getopt将单个连字符解释-help为表示组合选项列表，因此它解释为-h -e -l -p.
Additionally, when options take arguments (conventionally called “optargs”), there are a few ways you can specify them. 以下——假设索引opt是o，并且opt需要 optarg ¹——也是等价的：
-oParameter,-o Parameter,--opt=Parameter,--opt Parameter
尽管该getopt库现在是一个广泛使用的标准，但许多早于它的工具（例如tar）仍然使用自己的解析设置，因此为什么tar -xjf等效于tar xjf.
TL;DR：getopt并不总是存在，因此程序员必须以自己的方式解析参数。但是，较新的工具通常使用它，因此它们的行为是理智和可预测的。
1 有一种没有很好记录的能力，可以让选项能够采用 optarg 但不需要一个。可选的 optargs 会导致各种烦人的事情，并导致一些更常见的指定选项的方法无效（因为它们会模棱两可）。幸运的是，采用可选参数的参数并不常见。