我们尽可能从命令行为processing arguments and switches遵循“标准”。例如，默认情况下，我们拥有用于命令行解析的Posix2和GNU standards。如果“显式关闭”命令行开关被认为是有害的？
但是，由于我们的实用程序是跨平台的，我们希望它们可以跨平台脚本访问，因此我们也尝试使其“健壮”。所以，我们含蓄地允许这两种形式：
myutil --longname
myutil /longname
这不是在所有情况下完美的，因为它可以有点含糊，如崩溃的“短”的开关名Posix的支持（这些是相同的）：
myutil -abcd
myutil -a -b -c -d
myutil /a /b /c /d
（...我们不支持折叠在Win平台“短名称”，因为这是不明确的。）
另一种跨平台的切换问题，这似乎有些奇怪的是“明确的OFF”开关，尾部“-”明确标识一个开关为“关闭”：
myutil -a-
myutil --longname-
myutil /a-
myutil /longname-
这是明确的，所以我们认为它是可以接受的。 （“显式的关闭”的“/a/”和“/longname/”看起来很奇怪，于是我们就与尾随“-”作为“跨平台的内部标准。”）
回想一下，这个历史的“显性关”对于开关有时可用于明确“关闭”默认为“开”的值，或者删除以前可能已添加到命令行的开关（例如，在组装命令行时）脚本，稍后决定“删除”以前添加的开关）。
但是，在审查后：这个“明确关闭”开关可以被认为是有害的（坏形式）？
例如，如果一个实用程序默认为 “-v”（--verbose） “上”，我们可以有一个 “负开关” 将其关闭：
myutil -v-
.. 。或者，我们可以仅仅定义一个“-q”（--quiet）为“积极开关”隐式打开“上”一“安静“选项（这意味着一个” 关闭“为” -v“开关）：
myutil -q
当然，对于任何给定的用途，它随后将被冗余以同时支持” -v- “和”-q“形式，因为他们会做同样的事情。 （在这个例子中，另一个选项是多个“详细级别”，其中一个级别为“安静”，但目标是说明明确禁用交换机的“开/关”特性。）
一个详尽的网络搜索是浪费了太多的时间之后，似乎开关“明确关”已基本失宠（例如，它甚至没有在(Gnu) "Standards for Command Line Interfaces".提到的）这些天
问题：开关的历史“显式关闭”是否应该被认为是有害的？
而不是支持“负开关”，应新的命令行工具，转而青睐“正开关”或命令行选项对包括-水平“好表”？）如果是这样，是那么甚至有理由支持“显式关闭”开关了（今天编写的新公用程序）？
请为'explicit off'提供参考。在我阅读Sun和AIX手册的几年（有些Linux和其他人都在）中，我从来没有看到过用'-'来表示'关闭'。祝你好运！ – shellter
@shellter：我很少看到这个，但是一个例子是Debian的'aptitude'命令，其中'aptitude install foo-'实际上意味着“卸载foo”并且'aptitude remove foo +'实际上意味着“安装foo”。这意味着您可以方便地同时进行这两种操作。 'aptitude install bar foo-'其中安装了bar但删除了foo。我知道我在其他地方也看到了'-'的尾随，但我目前无法回想起在哪里。 – Sorpigal
我想知道'explicit off'概念是否从非Unix/Linux OS_s的旧代码中蹦入某些开源项目，可能是DEC或类似的东西？无论如何，它似乎进一步泥泞了命令行处理的水，并且很难看到它如何增加价值。对于用'-'和'+'标记的参数暗含的倒置含义已经够糟糕了。如果您发现有关'explicit off'的来源和/或好处的其他信息，请编辑您的问题或添加其他评论。祝你好运！ – shellter