我们尽可能地从命令行对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平台上折叠“短名称”，因为这是不明确的。）
另一个看起来有点奇怪的跨平台切换问题是“显式关闭”开关，其中尾随的“-”明确地将开关识别为“关闭”：
myutil -a-
myutil --longname-
myutil /a-
myutil /longname-
这是明确的，所以我们认为这是可以接受的。 （“/a/”和“/longname/”的“明确关闭”看起来很奇怪，所以我们将尾随的“-”作为“跨平台内部标准”。）
回想一下，交换机的历史“显式关闭”有时可用于明确“关闭”默认为“打开”的值，或者删除之前可能已添加到命令行的交换机 - 组装（例如从脚本组装命令行时，稍后决定“删除”以前添加的开关）。
但是，经过审核：此“明确关闭”切换是否会被视为有害（不良形式）？
例如，如果实用程序默认为“-v”（--verbose）为“on”，我们可能会有一个“ 否定开关“把它关掉：
myutil -v-
...或者，我们只能将“-q”（--quiet）定义为“ 正面开关”，隐式转为“ on ”a“ quiet ”选项（暗示“{em> off ”表示“-v”开关）：
myutil -q
当然，对于任何给定的实用程序，它将是多余的以支持“-v-”和“-q”形式，因为它们也会这样做事情。 （在此示例中，另一个选项是多个“详细级别”，其中一个级别为“安静”，但目标是说明明确禁用开关的“开/关”性质。）
经过漫长的网络搜索浪费了太多时间之后，似乎“显性关闭”的转变在很大程度上已经失宠（例如，(Gnu) "Standards for Command Line Interfaces".中甚至没有提及）
问题：交换机的历史性“明确关闭”是否应视为有害？
新的命令行实用程序不是支持“负面切换”，而是支持“正向切换”或命令行选项到包含级别作为“良好形式”？）如果是这样，是甚至有理由支持“显式关闭”开关（对于今天创作的新实用程序）？
答案 0 :(得分：2)
我从来没有听说过关闭开关的-。在UNIX-land中，它使用no-前面的--no-verbose与--verbose关闭OptionParser。至少，Ruby的--force直接支持这一点;不确定别人。
至于这种模式＆＃34;有害＆＃34;：绝对不是。拥有流畅的评论界面总是好的。考虑像--force这样覆盖现有文件的更具破坏性的选项。进一步考虑一种方案，其中用户可以为给定命令指定其默认命令行选项。现在，如果她已配置--force默认情况下处于启用状态;如何根据具体情况将其关闭？
我们不希望她编辑她的配置文件以禁用--no-force，因此我们提供3 * 1 * * awesome_script.sh --force my_files
0 * * * * awesome_script.sh --no-force my_files
来覆盖它。
可忽略的长格式选项在其他脚本或crontabs中也很有用，可以非常清楚地发生了什么：
awesome_script.sh必须保持这种差劲的系统管理员不会被打败。必须去寻找{{1}}的文件（假设它甚至存在）才能知道这里发生了什么。