Question

We try to follow “standards” as best we can for processing arguments and switches from the command line. For example, by default, we embrace Posix2 and GNU standards for command line parsing.

However, since our utilities are cross-platform, and we want them to be accessible from cross-platform scripts, we also try to be “robust”. So, we implicitly permit both forms:

  myutil --longname

  myutil /longname

This is not perfect in all cases, as it can be somewhat ambiguous, such as Posix support for collapsing “short” switch names (these are the same):

  myutil -abcd
  myutil -a -b -c -d
  myutil /a /b /c /d

(…we do not support collapsing “short names” on Win platforms because that is ambiguous.)

Another cross-platform switch issue that seems a little strange is the “explicit off” switch, where a trailing “-” explicitly identifies a switch as being “turned off”:

  myutil -a-
  myutil --longname-
  myutil /a-
  myutil /longname-

This is unambiguous, so we decided it acceptable. (The “explicit off” of “/a/” and “/longname/” looked really strange, so we went with the trailing “-” as a “cross-platform internal standard”.)

Recall that this historical “explicit off” for switches was sometimes useful to explicitly “turn off” a value that defaulted to “on”, or to remove a switch that may previously have been added to a command-line-being-assembled (such as when assembling a command line from a script where a later decision is made to “remove” a previously added switch).

HOWEVER, upon review: Can this “explicit off” switch be considered harmful (bad form)?

For example, if a utility defaults to “-v” (--verbose) as “on”, we could have a “negative switch” to turn it off:

  myutil -v-

…or, we could merely define a “-q” (--quiet) as a “positive switch” that implicitly turns “on” a “quiet” option (which implies an “off” for the “-v” switch):

  myutil -q

Of course, for any given utility, it would then be redundant to support both the “-v-” and “-q” forms, since they would do the same thing. (In this example, another option would be multiple “verbose levels” with one level being “quiet”, but the goal is to illustrate the “on/off” nature of explicitly disabling a switch.)

After an exhaustive web search that wasted far too much time, it seems the switch “explicit off” has largely fallen out of favor these days (for example, it is not even mentioned in the (Gnu) “Standards for Command Line Interfaces”.)

QUESTION: Should the historic “explicit off” for switches be considered harmful?

Rather than support a “negative switch”, should new command line utilities instead favor a “positive switch” or command-line-option-to-include-levels as “good form”?) If so, is there even a reason to support “explicit off” switches anymore (for new utilities authored today)?

Answer 1

I’ve never heard of a trailing - for turning off a switch. In UNIX-land, it’s using preceding it with no- as in --no-verbose turns off --verbose. At the very least, Ruby’s OptionParser supports this directly; not sure about others.

As to this pattern “being harmful”: absolutely not. It’s always good to have a fluent comment-line interface. Consider a more destructive option like --force that overwrites existing files. Consider further, a scheme where a user can specify her default command-line options for a given command. Now, if she’s configured --force to be on by default; how does turn it off on a case-by-case basis?

We don’t want her to edit her config file to disable --force, so we provide --no-force to override it.

Negatable long-form options can also be helpful in other scripts or crontabs to make it very clear what’s going on:

3 * 1 * * awesome_script.sh --force my_files
0 * * * * awesome_script.sh --no-force my_files

The poor sysadmin that must maintain this won’t’ have to go hunting for awesome_script.sh‘s documentation (assuming it even exists) to know what’s going on here.