如果没有,是否有一个事实上的标准? 基本上我正在写一个命令行帮助文本如下所示:
usage: app_name [options] required_input required_input2
options:
-a, --argument Does something
-b required Does something with "required"
-c, --command required Something else
-d [optlistitem1 optlistitem 2 ... ] Something with list
我提出,从基本上只是阅读的各种工具帮助文本,但有没有准则或某事的清单? 比如,我用方括号或括号? 如何使用空间? 如果该参数是什么列表? 谢谢!
通常情况下,你的帮助输出应包括:
- 的应用程序做什么说明
- 用法语法,其中:
- 用途
[options]
以指示选择去 -
arg_name
的需要,单数ARG -
[arg_name]
用于可选的,单数ARG -
arg_name…
对于需要ARG其中可以有很多(这是罕见的) -
[arg_name…]
对于其中任何数目的能够供给一个ARG - 注意,
arg_name
应该是描述性的,短的名字,在低,蛇的情况下
- 选项一个很好的格式列表,每个:
- 具有短的描述
- 示出的默认值,如果有一个
- 示出可能的值,如果适用
- 请注意,如果一个选项可以接受缩写形式(如
-l
)或长形式(例如--list
),同时包括他们在同一行,因为它们的描述将是相同的
- 的配置文件或环境变量的位置简要的指标,可能是命令行参数,例如源
GREP_OPTS
- 如果有一个男人页,表明正因为如此,否则,这里更详细的帮助,可以发现一个简单的指标
此外,值得注意的是它的好形式,同时接受-h
和--help
来触发此消息,并且 ,如果用户弄乱的命令行语法,例如省略了必需的参数,你应该显示此消息。
看看docopt 。 这是记录(自动解析)命令行参数的正式标准。
例如...
Usage:
my_program command --option <argument>
my_program [<optional-argument>]
my_program --another-option=<with-argument>
my_program (--either-that-option | <or-this-argument>)
my_program <repeating-argument> <repeating-argument>...
我们运行的是Linux,一大部分是POSIX兼容的操作系统。 POSIX标准,它应该是: 实用程序参数语法 。
GNU编码标准是这样的事情一个很好的参考。 本节与输出涉及--help
。 在这种情况下,它是不是很具体。 你可能不能出差错打印出短期和长期的选项和简洁的说明表。 尽量让所有的参数之间的间距正确的可读性。 你可能想提供一个man
页面(以及可能的info
为你的工具,以提供更详尽的说明手册)。
微软有自己的命令行标准规格 :
本文的重点是在命令行实用程序的开发人员。 总的来说,我们的目标是提供一致的,可组合的命令行的用户体验。 实现允许用户学习一套核心的概念(语法,命名,行为等),然后就可以到知识转化为具有较大的命令集的工作。 这些命令应该能够以标准化的格式的数据的输出标准化流,以允许容易地组合物而不输出文本解析流的负担。 该文档被写入到独立于任何特定的实现一个外壳,设置的公用设施或指令生成技术的; 然而,附录的J - 使用Windows PowerShell实现微软命令行标准说明了如何使用Windows PowerShell将提供许多执行这些准则免费的。
是的,你是在正确的轨道上。
是的,方括号是可选的项目通常的指标。
通常情况下,当你已经勾勒出来,有一个命令行总结在顶部,其次是细节,最好有每个选项的样本。 (你的例子显示了每个选项的描述之间的界线,但我认为这是一个编辑的问题,你的真正的程序输出缩进选项列表,中间没有任何空行。这是在任何情况下遵循的标准。)
一个较新的趋势,(也许有一个POSIX规范,解决这个?),是男人页系统的文档消除,并包括所有的信息,这将是一个手册页的部分program --help
输出。 这种额外的将包括更详细的描述,概念解释,使用的样品,已知的限制和缺陷,如何报告错误,可能是一个“另见”相关命令部分。
我希望这有帮助。
我会按照像焦油作为一个例子正式项目。 在我看来帮助味精。 需要是简单的和描述性越好。 使用的例子也很好。 没有为“标准帮助”没有真正的需要。