2

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)?

Community
  • 1
  • 1
charley
  • 5,913
  • 1
  • 33
  • 58
  • 1
    please provide a reference for `explicit off`. In my years of reading Sun and AIX manpages (with some Linux and others thrown in), I've never seen trailing `-` to indicate 'turn it off'. Good luck! – shellter Jul 19 '11 at 02:28
  • @shellter: I have seen this rarely, but one example is Debian's `aptitude` command where `aptitude install foo-` actually means "uninstall foo" and `aptitude remove foo+` actually means "install foo". This means you can do both at once conveniently, e.g. `aptitude install bar foo-` which installs bar but removes foo. I know I've seen trailing `-` used elsewhere, too, but I cannot presently recall where. – sorpigal Jul 20 '11 at 18:48
  • I'm wondering if the `explicit off` concept crept into some opensource projects from older code from non-Unix/Linux OS_s, maybe DEC or something like that? In any case, it seems to further muddy the water of command line processing and its hard to see how it adds value. It is bad enough with the inverted meanings implied for args flagged with `-` and `+`. If you find other info about the source of, and/or the benefit of `explicit off`, please edit your question or add another comment. Good luck! – shellter Jul 20 '11 at 22:41
  • you might also submit this question to other forums where such things would be considered an interesting sidebar, i.e. comp.unix.shell inet newsgroup would possibly be appropriate. Good luck2! – shellter Jul 20 '11 at 22:44

1 Answers1

2

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.

davetron5000
  • 24,123
  • 11
  • 70
  • 98