44

  • ls -a (I consider -a an option)

  • sudo -u username (-u = option, username = arg)

  • chmod 664 my-dir (664 = option, my-dir = arg)

I can't think of an example that might say "this is a flag" except perhaps when looking at dir listing:

-r--------. 1 david david   3344 May 19 17:48 611056.pdf

This has the "read flag" set for the owner, but that's all. What's to stop me from calling that a "read option"?

I write and edit technical documentation, primarily in DocBook XML, and I'm looking for an explanation of the difference, which is consistent and accurate as possible. However, I'm already seeing a pattern forming:

  1. flags tend to be Booleans. e.g., setenforce 0
  2. options help define how a command should behave. Some may be optional.
  3. arguments tell commands what object to operate on.

I could see myself combining flags and options (some options may have a dozen possible values, but Booleans only have two). Arguments appear sufficiently different to maintain them as such.

Kusalananda
  • 333,661
  • 2
    "What's to stop me from calling …"? O.o Nothing. Just as nothing stops me from calling a spade a tree. – muru May 26 '16 at 03:51
  • @muru - although an English dictionary will disagree with your assertion. –  May 26 '16 at 04:12
  • 3
    To make things more confusing, I'd also call an option that does not take a parameter/argument a flag, as in your ls -a example. (To me, a flag is a boolean variable.) – Ulrich Schwarz May 26 '16 at 05:06
  • 4
    They're dog kennels; all thirty of them.    :-)     ⁠ – Scott - Слава Україні May 26 '16 at 06:02
  • The pattern that you see is only there because you narrow down the things you want to see. One way to create a TAR file (that I have been using for more than 30 years) and not e.g. extract it is: tar c abc.txt > x.tar, in there c is a function. You are trying to call that an option and that is completely inappropriate. – Anthon May 26 '16 at 14:05
  • 2
    // , This isn't opinion based. There is a specific, correct, and quite useful answer to this. Re-open it, now. – Nathan Basanese Jun 04 '18 at 18:29
  • 2
    Not everything in the Linux/Unix world uses Posix terminology precisely, but it does define many of these terms: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html – Adrian McCarthy Feb 03 '21 at 14:24
  • Another more or less standard resource, from GNU Coding Standards: http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces – Bondolin Sep 30 '21 at 15:30

2 Answers2

39

There are no consistent definitions of the terms "option", "argument", and "flag", and there is no central authority within the software development world that could enforce their usage. This happens with much terminology: after 30+ years of using the word "directory", I now have to deal with people using the word "folder" who have been confused by Microsoft's new-speak.

There are different ways that consensus definitions for terms can come about in programming. In the case of "argument"/"option"/"flag", canonical manuals and tutorials for programming languages have helped to enforce usage, as has the terms used in common libraries.

For instance, the things you put on the command line after a command are often called "arguments" to the command, by analogy with arguments to a function call, and this is probably partly because they are called "arguments" in the C manual (hence argc and argv). The argparse Python library also helps to enforce the term "argument". However, I have also seen them being called "parameters".

The term "option" is derived from "optional", which implies they can be left out. The getopt C library is one use of this term. But there is precedent for "options" that are not actually optional: for example, the argparse manual states that one can create a "required option" (although it also says that this is "generally considered bad form"). Options are often preceded by a single (-) or double (--, long-option) dash, but there are well-known commands that do not require or enforce dash usage for options (e.g., tar, ps, and dd). An option can itself take an argument (e.g., -w80 and --color=always), or occasionally multiple arguments.

"Flags" are, in my experience, the same as options, but usually do not take arguments themselves and essentially represent boolean on-off switches.

On a broader note, since every programmer has the option to try and look up some standard way of doing things and naming things, but can also reinvent the wheel without much extra cost, naming is never going to be consistent. And once you have documented your code, and it is clear what new meaning you have given to these words by giving examples, those names and meanings might just stick if there are enough people who pick them up from your code.

Krister Janmore
  • 15
Anthon
  • 79,293
  • 4
    Just to add to this, I've seen various organizations enforce a distinction between "parameter" and "argument", e.g. https://developer.mozilla.org/en-US/docs/Glossary/Parameter "A parameter is a named variable passed into a function. Function arguments are the real values passed to the function." – Marcel Besixdouze Jul 15 '20 at 15:40
  • 6
    "there is no central authority" -- In the Unix/Linux world, there is the Open Group's Posix standard. Arguments are the tokens on the command line. The first argument is the utility name. Options are generally optional and modify the utility's default behavior. They are distinguished from other arguments by a leading -. The . An option may have an option argument. The remaining arguments are operands. Granted, not everything strictly follows Posix terminology, often for historical reasons. Flag and switch are informal jargon for a boolean-valued option. – Adrian McCarthy Feb 03 '21 at 14:21
  • @MarcelBesixdouze And at the same time in the bash manpage it is written "A variable is a parameter denoted by a name." Although in the context of bash, "name" has the special restricted meaning of "A word consisting only of alphanumeric characters and underscores, and beginning with an alphabetic character or an underscore." – The Quark Oct 19 '21 at 06:58
  • There do have semi-formal definitions for all programming languages. Given C and shell languages are all programming languages, the internal definitions are consistent with the common sense. C used to use informal phrases like "formal arguments" and "actual parameters", but finally deprecated and the normative uses are "formal parameter" and "actual arguments". In a broder sense, for all PLs, arguments are entities evaluated from operands, which are syntactic categories appertain to function application. – FrankHB May 26 '23 at 06:11
  • Command line arguments are (parts) arguments to C's main function in the sense of interoperations. OTOH, arguments to other command line components are just like arguments to functions, in the sense that arguments and the "subject" (either the command line option or the function) are handled together. – FrankHB May 26 '23 at 06:22
  • Not all PLs enforce applicative functions. Some operands to those function combinations may have non-strict evaluation, i.e. not guaranteed evaluated. Such operands remain operands during evaluation of the combination, and not arguments. Operands to normals functions of lazy languages (in some variant of "normal order" of evaluation, like call by need) and some special forms in Lisps (notably, quote) fall in this category. Function-like macros in C (macro expansion = call by macro argument replacement) are also more or less similar: not guaranteed applicative. – FrankHB May 26 '23 at 06:24
  • Parameters are not that general. In C-like languages, parameters are formal placeholders (more formally, bound variables) of functions (or macros); while in Scheme, parameters are key variables having dynamic scoping rules - different to the default (lexical) one. Such variety is also consistent to math: math parameters are not things just behave as variables (e.g. parameteric functions); they can be parmeterized totally differently, independently to the mechanisms of variable bindings (substitutions in calculi implying the operational semantics, or environment mutations in ordinary PLs). – FrankHB May 26 '23 at 06:30
24

A flag is a type of option, an option of boolean type, and is always false by default (e.g. --verbose, --quiet, --all, --long, etc).

An option tells the function how to act (e.g. -a, -l, --verbose, --output , -name , -c , etc), whist an arguments tells the function what to act on/from (e.g. *, file1, hostname, database).

Ezequiel Tolnay
  • 545
  • So in your definition, in git pull git://bla/bla, the pull is an argument that tells gitwhat to work on. – Anthon May 26 '16 at 05:56
  • 3
    @Anthon no, there are operators (switches/flags/parameters), arguments, and commands. pull is a command. One can think of commands as extensions of the application's name: git pull <...> is equivalent to an application called git-pull. When the application has commands, each command makes the application do something completely different. – Ezequiel Tolnay May 26 '16 at 06:42
  • 3
    The git people might call it a command, but that is not always what it is called e.g. for tar, using c for creating is called a function. And that is exactly the problem: there is no standardisation of terms, even if it looks like you think there is from your answer – Anthon May 26 '16 at 07:46
  • 2
    a flag doesn't have to be false by default. providing the flag on the command line just reverses its default state (on-->off, or off-->on). some people call that a toggle to distinguish it from a flag. others think the distinction is unimportant. – cas May 26 '16 at 08:16
  • 1
    @Anthon There exists the standardized meaning for "command": the shell "command" language is standardized as a part of POSIX. However, to be more precise, the "command" pull in this context should be a subcommand because it is not handled as a command by the shell; git-pull is the corresponding command. "Function" in this context is far less popular due to the ambiguity to the well-defined meaning of "function" in various programming languages and math (though actually it is not that well-defined in math). – FrankHB May 26 '23 at 06:49