single hyphen followed by one letter. multiple flags may cluster, such as -abc meaning -a -b -c. a value may attach (-ofile) or follow as the next token (-o file), depending on the utility.
double hyphen followed by a long name, such as --output. a value may attach with an equals sign (--output=file) or follow as the next token (--output file). short options coexist with long ones.
single hyphen followed by one letter. no long options. many utilities do not accept clusters, so -abc is an error unless explicitly defined. parsing often stops at the first non-option token.
slash-prefixed names, such as /v or /verbose. value attachment rules vary by command. some tools allow colon-delimited values (/o:fn.txt), others accept no values at all.
single-letter options only. no clustering. all options must occur first in argv. a standalone -- stops option parsing. unknown options cause the parser to stop and treat the remainder as positional arguments to allow arguments that start with - without having to use --.
addresses how options and positional arguments coexist and how the parser should treat ordering and grouping.
define the boundary between flags and data. for example, in cp -r dir1 dir2, -r is an option and the following two tokens are positional arguments.
some parsers allow options to appear after positional arguments, such as tar cf out.tar -v directory. others forbid this for performance or simplicity.
a literal -- indicates that all following tokens are positional, even if they begin with hyphens. example: grep -- -pattern file.
some flags require a value (-o file), others may accept an optional value (--level[=n]). the parser must determine whether to consume the next token.
a command may declare certain options as mandatory (for example pack --target t). others may be optional with defaults.
values may need conversion to numbers, paths, or domain-specific types. example: --implicit-compression=8 interpreted as integer.
commands such as git add introduce a verb hierarchy, each with its own option and argument rules.
defines the meaning of parsed structures once the raw tokens are consumed.
a system must decide whether a leading token like content is a command name or an argument. command-first systems reserve certain leading tokens for dispatch.
some tools require options to precede commands, while others accept interleaving. example: program command -v vs program -v command.
rules for whether an option may appear multiple times. example: -I path can be repeated in compilers.
values may be interpreted as integer, string, or other types. misinterpretation is avoided by declaring expected types.
transform raw values into internal forms (for example number parsing) and reject invalid ones early.
many tools treat -h and --help as the same option. the parser maintains aliases that map to the same key.
if an option is omitted, the parser may synthesize a value. example: no --compression implies compression=0.
some programs interpret options only in particular phases or after certain arguments appear. the option meaning depends on prior context rather than on a global flat namespace.
for example, find -type f -exec cmd {} + treats -exec differently depending on the preceding primaries. imagemagick resembles a pipeline: options such as -resize or -gravity apply only to the subsequent operands until another image boundary or operator resets context.
a context sensitive parser maintains an internal mode that changes as certain tokens are consumed. each mode exposes a different option set. this enables compact grammars but requires sequential interpretation rather than isolated option lookup.
the parser may stop scanning when encountering a non-option or an explicit --. what follows becomes positional.
unknown flags may cause immediate failure or may end option parsing.
a common example is how string matcher such as grep require -- before specifying patterns that start with a minus. otherwise it will exit with an error about an unknown option being used.
if an option requires a value but none is present, the parser either errors or halts. example: -o without a filename.
determining whether a token like -abc refers to clustered short options or a literal argument.
constraints on memory and cycles. example: sph-options scans argv once, uses a 256-entry table, and avoids allocations.
specifies who owns parsed strings and how long they remain valid. many parsers return pointers into argv for zero-copy behavior.
approaches used to implement an option parser.
state machine defined by posix. handles clustered short options and optional values according to an options string.
gnu extension that supports long names and equals-sign attachment. it returns both the resolved option and the index of the next argument.
manual iteration over argv implementing custom rules. used for minimal ad-hoc parsers: read token, check first character, dispatch or break.
process argv with a left fold: each token updates an accumulating parser state. srfi-37 uses this to uniformly handle flags and arguments.
a specification table defines each option: names, value requirements, and handlers. the parser dispatches operations by table lookup.
ways to specify an interface so the parser can operate generically.
flat arrays or tables indicating which options exist and whether they require values.
structured definitions including commands, options, and argument patterns. example: sph-cli with (cli-create #:options ... #:commands ...).
configuration passed as named parameters, often in scheme or dynamic languages. enables fine-grained tuning per option.
reporting for user-visible errors and metadata.
automatic formatting of commands, options, and argument patterns into structured help text.
machine-readable dumps describing options, argument patterns, and command structures.
structured messages such as 1 missing argument (facets content-id ...).
errors when encountering unknown flags, such as unsupported option xyz.
alternative philosophies for how strictly the system interprets tokens.
reject unknown or misformatted tokens immediately; enforce full specification adherence.
treat unknown tokens as positional arguments; delay errors until deeper stages.
attempt to match positional patterns before recognizing options; suitable for pattern-heavy interfaces.
scan options greedily from the start, then hand the rest to command or argument processing.
future adjustments that enhance expressiveness.
allow patterns that require at least one instance of an argument, distinct from zero-or-more.
add richer validations such as file-exists or directory-writable.