On Unix system, options begin with - is short option, while options begin with -- is long option. Is my understanding right?

  • 3
    Generally but not always. For instance find options have no single-letter abbreviations, but only have one leading hyphen. find . -name '*.txt' – Wildcard Jan 26 '16 at 4:13
  • 2
    yeah typically. the trick for long options is to make - an option letter. there's an answer here somewhere - (i thought it was one of @glennjackman's but cant find it now) about it. but: while getopts :-:others valid_name -params --long_is_in_OPTARG; do :; done – mikeserv Jan 26 '16 at 4:23
  • 1
    Related: Why does my ls --help not work? – Stéphane Chazelas Jan 26 '16 at 14:20
  • 2
    @Wildcard, those are not options but predicates / operators. find does accept single letter options (-H, -L...), the GNU implementations long options (--help, --version). Like for many other command, you can end those options with --, after which you can pass regular arguments (file paths and predicates some of which start with - (-a, -print...) some of which don't (!, (...)). – Stéphane Chazelas Jan 26 '16 at 14:31
  • 2
    I stand corrected. The most helpful single sentence I've read about find is: "find's business is evaluating expressions -- not locating files. Yes, find certainly locates files; but that's really just a side effect." So of course, makes sense that those are operands (or predicates, or operators), not options. – Wildcard Jan 26 '16 at 16:22

That is part of the GNU coding standards, so all GNU (and many non-GNU) software follows it. However, it's by no means an absolute standard; there are other ways of implementing this, such as:

  • -Wlong-option: originated from the C compiler, and specified as such in POSIX.
  • -long-option (i.e., single-dash): supported by most applications (usually as an alternative to the double-dash version) that don't have any short options.
  • +long-option: this is getting out of fashion, but there are a few older software packages that reserved the dash for short options, and the plus sign for long options. Not used much today, mostly because most getopt() implementations don't support it
  • long-option: unfortunately there are also some applications which confuse options with arguments. I believe MegaCLI is one of the offenders there (it is an offender in pretty much everything else, anyway).
| improve this answer | |
  • 1
    dd is, I guess, the canonical offender of the last kind; and tar and ps have odd argument conventions, too. – Ulrich Schwarz Jan 26 '16 at 8:26
  • This is often explained as "BSD ps", but in fact the BSD ps switched to getopt in 1990, and isn't the example that it is claimed to be. unix.stackexchange.com/a/511530/5132 – JdeBP Aug 22 at 20:32

The --long-opt method is a GNUism that has been initiated around 1990.

Multics uses -long options with a single dash and the Multics project was initiated the 1960s.

UNOS is the first UNIX clone (initiated by a group of former AT&T employees in 1980) and UNOS introduced a generalized option parser (the first in the UNIX world) in April 1982. This option parser supported -long options with a single dash.

AT&T introduced getopt() between 1983 and 1984, but getopt() was not reentrant before an additional 4th global variable has been introduced in 1989 for the Bourne Shell's builtin getopts.

POSIX implements operands that look like long options with a single dash with test and find

AT&T UNIX introduced -long options using a single dash around 1983 while permitting e.g. kill -INT <pid>.

tar and ar did not use the term option in their documentation at all but rather used the term keyletter. Later, implementors added support for a - keyletter that is ignored, giving the impression that y CLI may look like other UNIX commands.

dd uses an own option model, but this option model is compatible with the long option model from UNOS that defines long options to be in the following form:

  • -long
  • -long arg
  • long=arg
  • -long=arg
  • long= arg
  • -long= arg

The UNOS option parser is superior to the GNU longopt implementation as it uses a format string that allows to auto-convert integer and boolean arguments and as it allows to implement callback functions for eny option if desired. There is no need to reorder the argument list because of the callback function interface.

The Solaris getopt() implementation supports long options as aliases to short options since 2004 but did not really document it even though it was usable by the Bourne Shell via getopts(1)since it was introduced.

The Schily Bourne Shell documents this feature and in addition introduced further getopt() enhancements that permit long options that are not just aliases to a short option and that permit single dash long options.

See http://schillix.sourceforge.net/man/man1/bosh.1.html in the builtin commands section for getopts.

A modernized and enhanced option parser that is based on the ideas of the UNOS option parser is in the schily-tools in libschily/getargs.c


it is used in the schily tool programs that are not based on AT&T code and results in less problems with unhappy defined options names such as in mkisofs

| improve this answer | |
  • Go's standard option parsing works very like UNOS's, so I guess that's where Go got its inspiration. – muru Jan 26 '16 at 14:32
  • go does not seem to support a format string similar to what getargs() offers. – schily Jan 26 '16 at 16:12
  • Nope. In go, each option is set up individually, and has an associated variable and type (so that conversion is also done automatically). And you can have one or two leading hyphens for long options. – muru Jan 26 '16 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.