我們儘可能從命令行爲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