设计命令行参数的良好习惯是什么？

#1 楼

在POSIX系统（例如Linux，MacOSX）上，至少对于可能在Shell终端中启动的程序（例如其中的大多数），我建议使用GNU编码约定（还列出了常用的参数名称），并查看POSIX实用程序指南，甚至对于专有软件：


总是处理--version和--help（甚至/bin/true也接受它们！）。我诅咒那些不了解--help的软件的作者，我讨厌他们（因为prog --help是我在新程序上尝试的第一个命令）！通常，--help可以缩写为-h
将--help消息列表列出所有选项（除非您有太多的选项...在这种情况下，请列出最常见的选项并明确引用某些man页面或某些URL）和选项的默认值，以及可能重要的（和特定于程序的）环境变量。在选项参数错误时显示这些选项列表。
接受-a短参数（单字母）并具有等效的--long-argument，因此-a2 --long-argument=2，--long-argument 2；当然，您可能会（对于很少使用的选项）使用一些--only-long-argument名称；对于没有额外选项的模态参数，通常将-cf处理为-c -f等，因此您的-argument:value提案很奇怪，因此我不建议这样做。 ...）
经常将Arg用于标准输入或输出（如果无法执行此操作，即使在少数几个没有它们的操作系统上也可以使用-和/dev/stdin）
通过模仿类似程序的行为重用其大多数选择约定；特别是/dev/stdout（用于空运行）（la -n），make（用于帮助），-h（用于详细说明）等。如果您的程序使用-v来测试stdin是否是终端（并且在这种情况下表现为“交互”），则提供一个选项来强制非交互模式，同样，如果您的程序具有GUI界面（并在X11桌面上测试--），也可以在批处理或命令行中使用。
某些程序（例如isatty）接受间接参数列表，因此getenv("DISPLAY")表示从gcc读取程序参数；当您的程序可能接受大量参数（而不是内核的@somefile.txt）时，这可能会很有用或somefile.txt）

一些旧的Unix命令（例如ARG_MAX甚至bash）具有奇怪的命令参数以实现历史兼容性。我建议不要遵循它们的坏习惯（除非您对它们进行一些改进）。

如果您的软件是一系列相关的命令行程序，请从git中得到启发（您肯定会使用作为开发工具），它可以接受zsh和dd并具有许多sed和git help git --help git

在极少数情况下，您也可以使用subcommand（通过在程序上使用符号链接），例如作为git调用的subcommand具有不同的行为（受限制的shell）。但是我通常不建议这样做；如果可以使用shebang将您的程序用作脚本解释器，即execve（2）解释的第一行上的--help，则可能有意义。如果您使用了这些技巧，请确保将它们记录下来，包括在argv[0]消息中。

请记住，在POSIX上，shell会混淆参数（在运行程序之前！），因此请避免使用字符（例如bash或rbash或#!）中的选项，这些选项需要进行转义。

在某些情况下，您可以在软件中嵌入诸如GNU guile或Lua之类的解释器（如果您不是编程语言专家，请避免发明自己的图灵完整脚本语言）。这会对软件的设计产生深远的影响（因此应尽早考虑！）。然后，您应该可以轻松地将一些脚本或表达式传递给该解释器。如果您采用这种有趣的方法，请谨慎设计软件及其解释的原语；您可能会有一些奇怪的用户为您的事情编写大型脚本。 。同样，这是一个非常重要的设计决定（因此，请谨慎定义和记录插件接口），并且您需要定义一个约定，以将程序选项传递给这些插件。

如果您的软件是一件复杂的事情，使其接受一些配置文件（另外或替换程序参数），并且可能有某种方法可以测试（或只是解析）这些配置文件而无需运行所有代码。例如，邮件传输代理（例如Exim或Postfix）非常复杂，能够“半干”运行它（例如，观察它如何处理某些给定的电子邮件地址而不实际发送电子邮件）很有用。


请注意，--help是Windows或VMS。在POSIX系统上这太疯狂了（因为文件层次结构使用*作为目录分隔符，并且因为shell会进行globbing）。我所有的答案主要是针对Linux（和POSIX）的。


P.S.如果可能的话，使您的程序成为免费软件，您会从某些用户和开发人员那里得到改进（添加新程序选项通常是添加到现有免费软件中最容易的事情之一）。
另外，您的问题在很大程度上取决于目标受众：针对青少年的游戏或针对祖母的浏览器可能不需要与编译器，数据中心sysadmin的网络检查器或微处理器的CAD软件相同的选项和数量建筑师或桥梁设计师。熟悉编程和脚本的工程师可能比奶奶更喜欢具有很多可调选项，并且可能希望能够在没有X11的情况下运行您的应用程序（也许在$中工作）。

#2 楼

数据格式约定很流行是它的优点。一点努力。对于人类来说，最大的努力就是记住“现在，这个不常用的程序是用:还是=来界定事物的？嗯……”天哪，没有令人信服的理由，请不要背离根深蒂固的惯例。人们会把您的程序记为“具有奇怪而烦人的cmdline语法的程序”，而不是“保存了我大学论文的程序”。

#3 楼

用外行术语来说，在罗马时，请像罗马人那样做。 Linux有用于轻松解析此类参数和标志的工具。

我通常会执行以下操作： -p value


如果CLI应用程序适用于Windows，则请使用--parameter value和while [[ $# > 0 ]] do key="" case $key in --dummy) #this is a flag do something here ;; --audit_sessiones) #this is a flag do something here ;; --destination_path) # this is a key-value parameter # the value is always in , # you must shift to skip over for the next iteration path= shift ;; *) # unknown option ;; esac shift done 约定。 Oracle实用程序使用/flag。
我想做的一件事是，除了在命令行中接受参数外，还提供使用parfile的选项，parfile是一个键值对文件，以避免冗长的参数链。为此，您应该提供一个附加的/flag:value参数。显然，如果使用PARAMETER=VALUE，则所有其他参数都将被丢弃，而转而使用parfile中的内容。 --parfile mifile.par。
在Linux中，不要忘记添加参数自动完成功能，这意味着用户可以键入半个开关，然后按--parfile，然后Shell会为他们完成该操作。

#4 楼

尚未出现的一件事：

尝试从命令行参数开始向上设计软件。
含义：

在设计功能之前，请先进行设计用户界面。

这将使您能够尽早深入研究边缘情况和常见情况。比仅编写所有代码然后再敲击CLI更好的结果。

此外，请查看docopt（http://docopt.org/）。

docopt在许多语言中都提供了很大的帮助，尤其是对于python而言，它的使用受到严重限制，像argparse这样的用户不利参数解析器仍然被认为是“确定”。定义语法帮助，其余的工作就会完成。

#5 楼

已经提供了一些有价值的评论（@ Florian，Basile），但让我添加一下...但是，一些高级管理员可能希望自己配置应用程序


但也要注意以下几点：


我不想将此问题作为平台或特定于语言的内容


您必须考虑目标受众-高级管理员。他们通常在什么平台上工作-Win / Unix / Mac？您的应用在什么平台上运行？遵循已为该平台建立的任何CLI约定。您的“高级”管理员是否想要/需要基于GUI的工具？

您希望界面在内部以及与其他管理员工具保持一致。我不想停下来思考这是cmd -p <arg>还是cmd -p:<arg>或cmd /p <arg>。我需要引号'cos那里有空格吗？我可以将cmd -p <val1> <val2>或cmd -p <val1> -p <val2>用于多个目标吗？它们是特定于订单的吗？可重载吗？ cmd -p2 <arg> -p1 <arg>也可以吗？ ls -l -r -t dir1 dir2 == ls -trl dir1 dir2吗？

对于我的Unix管理工具，我始终牢记Heiner的Shelldorado提供的指南以及所提到的其他参考文献。确保您的应用程序设计为使用与GUI中相同的命令行参数-即：GUI中没有业务逻辑，或使用从GUI和CLI调用的通用命令。

大多数基于UNIX的管理工具实际上都是首先设计为命令行工具的，而提供的GUI只是简化了“填充”命令行选项的工作。这种方法可以实现自动化，响应文件的使用等，还可以进行自动管理（对我而言，工作量更少！）

作为使用此方法的经典工具集，它是Tcl / Tk。不建议您切换工具；只需考虑以下设计方法：首先将基于GUI的管理应用程序编写为命令行工具即可；然后为方便起见将GUI放在最上面。在某些时候，如果您必须进行多个配置并一遍又一遍地重新输入相同的选项，并且可能会发现GUI是一种痛苦（并且容易出错），并且您会寻找一种自动化的方法。

请记住，无论如何，您的管理员很可能必须在正确的框中键入正确的值，所以您需要付出多少努力才能使用GUI？