On Unix system, options begin with - is short option, while options begin with -- is long option. Is my understanding right?
Asked
Active
Viewed 5,740 times
3
Gilles 'SO- stop being evil'
- 829,060
Nan Xiao
- 1,407
2 Answers
7
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 itlong-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).
Wouter Verhelst
- 9,331
-
1
ddis, I guess, the canonical offender of the last kind; andtarandpshave odd argument conventions, too. – Ulrich Schwarz Jan 26 '16 at 08:26 -
This is often explained as "BSD
ps", but in fact the BSDpsswitched togetoptin 1990, and isn't the example that it is claimed to be. https://unix.stackexchange.com/a/511530/5132 – JdeBP Aug 22 '20 at 20:32
6
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 arglong=arg-long=arglong= 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
http://sourceforge.net/projects/schilytools/files/
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
schily
- 19,173
-
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
findoptions have no single-letter abbreviations, but only have one leading hyphen.find . -name '*.txt'– Wildcard Jan 26 '16 at 04:13-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 04:23finddoes 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:31findis: "find's business is evaluating expressions -- not locating files. Yes,findcertainly 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:22primariesin the documentation. They still can be seen that there is a preference for single dash long options inUNIX- maybe because Multics uses single dash long options as well. – schily Jan 27 '16 at 09:15