ParseArgv Syntax
Help Text Syntax
A help text must follow these simple rules:
• All help text should be designed to be presented to the user as command line help.
• A command is recognized by a line with the following pattern:
usage: command
• A subcommand is recognized by a line with the following pattern:
usage: command subcommand
• Command line arguments must be enclosed with less-than/greater-than characters (<
and >
).
usage: command <argument>
• Optional arguments are enclosed in square brackets ([
and ]
).
usage: command [<argument>]
• Arguments to be collected in arrays are marked with three dots at the end.
usage: command <argument>...
usage: command [<argument>...]
• Options start after any number of spaces with a stroke (-
) and a single letter, or two strokes (--
)and a word, which must be followed by a descriptive text.
-s this is a boolean option (switch)
--switch this is a boolean option (switch)
• Options that are to be specified both as a word and its abbreviation can be combined with a comma (,
).
-s, --switch this is a boolean option (switch)
• Options that require an argument additionally define the name of the argument after the declaration, enclosed with less-than/greater-than characters (<
and >
).
-o <option> this is an option with the argument named "option"
--opt <option> this is an option with the argument named "option"
-o, --opt <option> this is an option with the argument named "option"
• If multiple subcommands are to be defined (git-like commands), the individual commands can be separated with a line beginning with a #
character.
usage: command
Options and helptext for "command" here...
#
This is the help text header for the subcommand
usage: command subcommand
Options and helptext for the subcommand here...
Command Line Syntax
Simple Arguments
A command line program using ParseArgv accepts all required and optional parameters as expected. The user will be notified of missing or excess parameters, if any.
Definition example:
usage: sample <infile> [<template>] <outfile>
The <infile>
and <outfile>
parameters are required. If they are not specified, the user will be notified.
sample ./source.md ./out.html
# ok, infile: "./source.md", outfile: "./out.html"
sample ./source.md
# error: "sample: argument missing - <outfile>"
If three parameters are specified in this example, the optional third parameter is also accepted.
sample ./source.md ./template.yaml ./out.html
# ok, infile: "./source.md", template: "./template.yaml", outfile: "./out.html"
If too many parameters are specified, the user will be notified.
sample ./source.md ./template.yaml ./out.html ./some.txt
# error: "sample: too many arguments"
Options
Consider the following definition example:
usage: sample <infile>
options:
-o, --out <outfile> specify output file name
-t, --template <template> use given template
-c. --colors enable color mode
-v, --verbose enable verbose mode
Here the user must specify a <infile>
parameter, can add optional (named) arguments (<outfile>
and <template>
) and select parameterless options (<colors>
and verbose
).
Since <infile>
is a required argument, it must always be specified, all other specifications are optional.
sample ./source.md
# ok, infile: "./source.md"
sample ./source.md --out ./result.html -c
# ok, infile: "./source.md", outfile: "./result.html", colors: true
The short forms of the options can also be combined.
sample ./source.md -voc ./result.html
# ok, infile: "./source.md", outfile: "./result.html", colors: true, verbose: true
To write down the affiliation of named parameters more clearly, the following notation is allowed.
sample ./source.md --out:./result.html -t=nice.yaml
# ok, infile: "./source.md", outfile: "./result.html", template: "nice.yaml"
Parameterless options can be understood as switches. Therefore it is possible to write them down like this:
sample ./source.md --colors:on -v:off
# ok, infile: "./source.md", colors: true, verbose: false