                                   -----------------
                                   Examples of Usage
                                   -----------------

Preamble

    The simplicity in JOpt "Simple" arises from two guiding principles:

    * Stick as often as possible to supporting conventional Unix option syntaxes.

    * Keep the surface area of the published API as small and simple as possible.

    []

    To the first principle: You will not see support in JOpt Simple for option "groups",
    alternative option prefixes (<<<+>>>, <<</>>>), enforced multiplicity of option
    arguments, etc.  JOpt Simple believes you can create a useful and understandable CLI
    without all that stuff.  If you feel as though you need any of those features, there
    are lots of other choices out there.  The author of JOpt Simple believes you'll want
    to leverage its easy configuration, parsing, and option interrogation APIs instead of
    using more feature-laden, but perhaps more confusing libraries.

    To the second principle: JOpt Simple will make every attempt to keep the API free
    of clutter.  The API is well factored, making it intuitive to use, and the entire
    library is well tested, making it more reliable and predictable.  If you cannot look
    at the Javadoc and quickly get a sense of what you need to do to use JOpt Simple,
    then JOpt Simple has failed.  So by all means, let the author know what needs
    improved.

    With that said, let's take a tour through JOpt Simple's features.

Options

    JOpt Simple supports short options and long options, using a syntax that attempts to
    take from the best of POSIX <<<getopt()>>> and GNU <<<getopt_long()>>>.

* Short Options

    Short options begin with a single hyphen (<<<->>>) followed by a single letter or
    digit, or question mark (<<<?>>>), or dot (<<<.>>>).

+----------------------------------------------------------------------------------------
@SHORT_OPTIONS_EXAMPLE@
+----------------------------------------------------------------------------------------

    When you construct an <<<OptionParser>>> with a string of short option characters,
    you configure that parser to recognize the options with those characters.

** Arguments of Options

    Short options can accept single arguments.  The argument can be made required or
    optional.  When you construct an <<<OptionParser>>> with a string of short option
    characters, append a single colon (<<<:>>>) to an option character to configure
    that option to require an argument.  Append two colons (<<<::>>>) to an option
    character to configure that option to accept an optional argument. Append an
    asterisk (<<<*>>>) to an option character, but before any "argument" indicators,
    to configure that option as a "help" option.

    The syntax of the option specification string given to the <<<OptionParser>>>
    constructor should look familiar to you if you have used GNU's <<<getopt()>>>
    before.

+----------------------------------------------------------------------------------------
@SHORT_OPTIONS_WITH_ARGUMENTS_EXAMPLE@
+----------------------------------------------------------------------------------------

*** Specifying Arguments for a Short Option on the Command Line

    A short option's argument can occur:

    * in the position on the command line after the option

    * right up against the option

    * right up against the option separated by an equals sign (<<<=>>>)

    []

+----------------------------------------------------------------------------------------
@SHORT_OPTIONS_WITH_ARGUMENT_POSITIONING_EXAMPLE@
+----------------------------------------------------------------------------------------

*** Multiple Arguments for a Single Option

    To specify <n> arguments for a single option, specify the option <n> times on the
    command line, once for each argument.  JOpt Simple reports the arguments given to the
    option in the order in which they were encountered on the command line.

+----------------------------------------------------------------------------------------
@SHORT_OPTIONS_WITH_MULTIPLE_ARGUMENTS_FOR_SINGLE_OPTION_EXAMPLE@
+----------------------------------------------------------------------------------------

** Clustering Short Options

    Short options can be <clustered> in a single argument.

+----------------------------------------------------------------------------------------
@SHORT_OPTIONS_CLUSTERING_EXAMPLE@
+----------------------------------------------------------------------------------------

    If one of the short options can accept an argument, the remaining characters are interpreted
    as the argument for that option.

+----------------------------------------------------------------------------------------
@SHORT_OPTIONS_CLUSTERING_WITH_ARGUMENT_EXAMPLE@
+----------------------------------------------------------------------------------------

* Long Options/Fluent Interface

    Long options begin with two hyphens (<<<-->>>), followed by multiple letters,
    digits, hyphens, question marks, or dots.  A hyphen cannot be the first character of
    a long option specification when configuring the parser.

    Whereas short options can be configured using a constructor argument to
    <<<OptionParser>>>, both long and short options can be configured using a "fluent
    interface" API, that enables some very descriptive and powerful features.

+----------------------------------------------------------------------------------------
@LONG_OPTIONS_EXAMPLE@
+----------------------------------------------------------------------------------------

** Arguments of Options

    Like short options, long options can accept single arguments.  The argument can be
    made required or optional.  Use the methods <<<withRequiredArg()>>> and
    <<<withOptionalArg()>>> on the return value of <<<OptionParser.accepts()>>> to signal
    that an option takes a required or optional argument.

+----------------------------------------------------------------------------------------
@LONG_OPTIONS_WITH_ARGUMENTS_EXAMPLE@
+----------------------------------------------------------------------------------------

** Abbreviating Long Options

    Notice in the example above that the command line uses abbreviations of command line
    options.  You can abbreviate options so long as the abbreviation is unambiguous.
    Even though you can abbreviate the options on the command line, you cannot address
    the <<<OptionSet>>> using those abbreviations. You can use a special constructor
    for the <<<OptionParser>>> that turns off abbreviation matching.

** Using Single Hyphen on Long Options

    As demonstrated in the example above, you can use a single hyphen instead of a
    double hyphen to specify a long option -- but be careful that doing so doesn't
    introduce ambiguity.

*** Specifying Arguments for a Long Option on the Command Line

    A long option's argument can occur:

    * in the position on the command line after the option

    * right up against the option separated by an equals sign (<<<=>>>)

    []

+----------------------------------------------------------------------------------------
@LONG_OPTIONS_WITH_ARGUMENT_POSITIONING_EXAMPLE@
+----------------------------------------------------------------------------------------

*** Multiple Arguments for a Single Option

    Specify multiple arguments for a long option in the same manner as for short options
    (see above).

** Alternative Form of Long Options

    The option <<<-W>>> is reserved. If you tell the parser to recognize alternative
    long options, then it will treat, for example, <<<-W foo=bar>>> as the long option
    <<<foo>>> with argument bar, as though you had written <<<--foo=bar>>>.

    You can specify <<<-W>>> as a valid short option, or use it as an abbreviation for a
    long option, but recognizing alternative long options will always supersede this
    behavior.

    To recognize alternative long options, either construct an <<<OptionParser>>> with a
    string of short option characters containing the sequence <<<W;>>> (a capital W
    followed by a semicolon), or call the method
    <<<OptionParser.recognizeAlternativeLongOptions()>>>.

+----------------------------------------------------------------------------------------
@ALTERNATIVE_LONG_OPTIONS_EXAMPLE@
+----------------------------------------------------------------------------------------

* Other Features

** Converting Option Arguments to Other Types

    Without action other than the <<<with*Arg()>>> methods, arguments of options are
    returned as <<<String>>>s.  For backwards compatibility,
    <<<OptionSet.valueOf(String)>>> and <<<OptionSet.valuesOf(String)>>> return
    <<<Object>>> and <<<List<?>>>>, respectively, so to get the values out as
    <<<String>>>s, you will need to downcast the results of those methods.

    You can tell JOpt Simple to convert the arguments of options to different Java types
    via the <<<ofType()>>> method on the return value of <<<with*Arg()>>>.  The
    <<<Class>>> argument of <<<ofType()>>> must represent a Java class that has either:

    * a <<<public static>>> method called <<<valueOf()>>> which accepts a single
    <<<String>>> argument and whose return type is the type itself, or

    * a <<<public>>> constructor which takes a single <<<String>>> argument.

    []

    If the class has both, the <<<valueOf()>>> method is used.

    Note that <<<enum>>>s have a <<<valueOf()>>> method.

+----------------------------------------------------------------------------------------
@OPTION_ARGUMENT_VALUE_TYPE_EXAMPLE@
+----------------------------------------------------------------------------------------

    Another way to convert arguments of options is to specify a converter object via
    <<<withValuesConvertedBy()>>>.  This is useful when the desired type for the arguments
    does not meet the requirements that <<<ofType()>>> sets forth.  Such objects may not
    perform any "conversion" at all, but rather can validate that arguments conform to
    certain restrictions before passing through as-is.

    You can also do this for the non-option arguments of your command line, if you desire
    to treat them all as a single type.

+----------------------------------------------------------------------------------------
@OPTION_ARGUMENT_CONVERTER_EXAMPLE@
+----------------------------------------------------------------------------------------

** Retrieving Arguments of Options in a Type-Safe Manner

    In the previous examples, we have been discarding the return values of the methods
    of JOpt Simple's fluent interface.  If instead you retain them in variables of type
    <<<OptionSpec>>>, you can use them to retrieve arguments of options in a type-safe
    manner.

    You can also do this for the non-option arguments of your command line, if you desire
    to treat them all as a single type.

+----------------------------------------------------------------------------------------
@TYPESAFE_OPTION_ARGUMENT_RETRIEVAL_EXAMPLE@
+----------------------------------------------------------------------------------------

** Exporting Options and Arguments to other Code

    As an integration aid for other libraries, you can use <<<OptionSet.asMap()>>> to
    obtain a mapping of <<<OptionSpec>>> to option values, for example to create a
    properties map of options.

    Here is sample code to create properties whose keys have a common prefix.  The key is
    choosen as the first non-short option:

+----------------------------------------------------------------------------------------
@EXPORTING_OPTIONS_AND_ARGUMENTS_EXAMPLE@
+----------------------------------------------------------------------------------------

** Default Values for Option Arguments

    Often it is convenient to specify default values for the arguments of certain
    command line options.  To do this, call the <<<defaultsTo()>>> method.

+----------------------------------------------------------------------------------------
@DEFAULT_VALUES_FOR_OPTION_ARGUMENTS_EXAMPLE@
+----------------------------------------------------------------------------------------

    You can see that <<<defaultsTo()>>> should relieve you of the burden of having to
    check <<<has()>>> and/or <<<hasArgument()>>> on an <<<OptionSet>>> for a given option,
    and has no bearing on the return values of those methods.  Specifying a default value
    for an option with a required argument does not mean that you can elide an argument for
    the option on the command line.

    The type of values <<<defaultsTo()>>> expects is dictated by the class given by a
    previous call to <<<ofType()>>> or <<<withValuesConvertedBy()>>>; if no such call has
    been made, the type is <<<String>>>.

** "Required" Options

    You can indicate that a given option must be present on the command line via the
    <<<required()>>> method.  Only options that accept arguments can be made "required".

    An option designated as a "help" option via <<<forHelp()>>>, when present on the
    command line, causes missing "required" options not to reject the command line.

+----------------------------------------------------------------------------------------
@REQUIRED_OPTIONS_EXAMPLE@
+----------------------------------------------------------------------------------------

** "Required" Dependent Options

    You can indicate that a given option must be present on the command line if some
    other option is present on the command line via the <<<requiredIf()>>> method.
    Any option can be made "required if".

    An option designated as a "help" option via <<<forHelp()>>>, when present on the
    command line, causes missing "required if" options not to reject the command line.

+----------------------------------------------------------------------------------------
@REQUIRED_IF_OPTIONS_EXAMPLE@
+----------------------------------------------------------------------------------------

    You can also indicate that a given option must be present on the command line if some
    other option is NOT present on the command line via the <<<requiredUnless()>>> method.
    Any option can be made "required unless", but, to avoid potential conflicts, it should
    not be "required if" at the same time.

+----------------------------------------------------------------------------------------
@REQUIRED_UNLESS_OPTIONS_EXAMPLE@
+----------------------------------------------------------------------------------------

** "Available" Dependent Options

    Similarly to <<<requiredIf()>>> and <<<requiredUnless()>>>, you can indicate that a
    given option can be present on the command line only if/unless some other option is
    present on the command line, via the <<<availableIf()>>> and <<<availableUnless()>>>
    methods.


** Synonyms of Options

    Sometimes it is useful to allow many different options to share the same meaning in
    the program that uses them.  To specify that options are to be treated as synonymous,
    use the <<<acceptsAll()>>> method of <<<OptionParser>>>.

+----------------------------------------------------------------------------------------
@OPTION_SYNONYM_EXAMPLE@
+----------------------------------------------------------------------------------------

** Concise Specification of Multiple Arguments for an Option

    Another way to specify multiple arguments for an option is to tell the parser to
    treat a single argument containing multiple delimited values as multiple arguments
    for the option using the <<<withValuesSeparatedBy()>>> method.

+----------------------------------------------------------------------------------------
@MULTIPLE_DELIMITED_ARGUMENTS_EXAMPLE@
+----------------------------------------------------------------------------------------

** Signalling End of Options

    An argument consisting only of two hyphens (<<<-->>>) signals that the remaining
    arguments are to be treated as non-options.

    An argument consisting only of a single hyphen is considered a non-option argument
    (though it can be an argument of an option).  Many Unix programs treat single hyphens
    as stand-ins for the standard input or standard output stream.

*** Non-Option Arguments

    Any arguments which are not options or arguments of options can be retrieved via
    method <<<nonOptionArguments()>>> on <<<OptionSet>>>.  If the double hyphen is an
    argument, it is ignored and is not a non-option argument.

+----------------------------------------------------------------------------------------
@SIGNALLING_END_OF_OPTIONS_EXAMPLE@
+----------------------------------------------------------------------------------------

** "POSIX-ly Correct"-ness

    By default, as with GNU <<<getopt()>>>, JOpt Simple allows intermixing of options and
    non-options.  If, however, the parser has been created to be "POSIX-ly correct", then
    the first argument that does not look lexically like an option, and is not a required
    argument of a preceding option, signals the end of options.  You can still bind
    optional arguments to their options using the abutting (for short options) or
    <<<=>>> syntax.

    Unlike GNU <<<getopt()>>>, JOptSimple does not honor the environment variable
    <<<POSIXLY_CORRECT>>>. "POSIX-ly correct" parsers are configured by either:

    * using the method <<<OptionParser.posixlyCorrect()>>>

    * using the <<<OptionParser>>> constructor with an argument whose first character is
    a plus sign (<<<+>>>)

    []

+----------------------------------------------------------------------------------------
@POSIXLY_CORRECT_EXAMPLE@
+----------------------------------------------------------------------------------------

** Special Optional Argument Handling

    If the parser detects an option whose argument is optional, and the next argument
    "looks like" an option, that argument is not treated as the argument to the option,
    but as a potentially valid option.  If, on the other hand, the optional argument is
    typed as a derivative of <<<Number>>>, then that argument is treated as the negative
    number argument of the option, even if the parser recognizes the corresponding numeric
    option.

+----------------------------------------------------------------------------------------
@SPECIAL_OPTIONAL_ARGUMENT_HANDLING_EXAMPLE@
+----------------------------------------------------------------------------------------

Generating Command Line Help

    When you call method <<<OptionParser.printHelpOn()>>>, JOpt Simple will write a
    help screen (80-column width) describing all the options it is configured with,
    along with types of option arguments, whether the option is required (in angle
    brackets) or optional (in square brackets), etc.  To give an option a description,
    use <<<OptionParser.accepts*()>>> with a description argument.  To give an option
    argument a description, use <<<describedAs()>>> on the return value of
    <<<with*Arg()>>>.

+----------------------------------------------------------------------------------------
@HELP_SCREEN_EXAMPLE@
+----------------------------------------------------------------------------------------

    Here is what the help screen looks like for the example above:

+----------------------------------------------------------------------------------------
@HELP_SCREEN_EXAMPLE_HELP@
+----------------------------------------------------------------------------------------

    If you want to create your own help screen, give method
    <<<OptionParser.formatHelpWith()>>> a <<<HelpFormatter>>> that builds the help screen
    as a String. When you call <<<OptionParser.printHelpOn()>>>, JOpt Simple will use
    your <<<HelpFormatter>>> to produce the help and write it to the given stream.

    For example, this program:

+----------------------------------------------------------------------------------------
@HELP_FORMATTER_EXAMPLE@
+----------------------------------------------------------------------------------------

    yields the following output:

+----------------------------------------------------------------------------------------
@HELP_FORMATTER_EXAMPLE_OUTPUT@
+----------------------------------------------------------------------------------------

Handling Exceptions

    JOpt Simple's classes raise some derivative of <<<OptionException>>> if they encounter
    problems during parsing.  These exceptions are unchecked, so you don't have to do
    anything with such an exception if you don't want to.  The rationale behind this
    decision is that you will most likely be invoking JOpt Simple's functionality from a
    <<<main()>>> method or very near to it, where a failure such as unrecognized arguments
    can just stop down the JVM and yield a stack trace without much user or programmer
    inconvenience.  So, without any exception handling at all, a user would see something
    like this:

+----------------------------------------------------------------------------------------
@EXAMPLE_STACK_TRACE@
+----------------------------------------------------------------------------------------

    If you want to handle the exception yourself, you can catch <<<OptionException>>> in
    your code, and do whatever you please with the contents of the exception, perhaps
    using the help generation facility.

* Suppressing <<<UnrecognizedOptionException>>>

    Sometimes you want to ignore unrecognized options on the command line.

    For example, you might be interested in handling only a part of the arguments given.
    Or you might want to pass on options to another program and not bother the user with
    providing two hyphens (<<<-->>>) to indicate the end of known options. Or maybe
    you want to provide future forwards/backwards compatibility when you foresee passing
    in new options to old code (or old code invoking new code with "old" arguments).

    You can achieve this by using the method <<<OptionParser.allowsUnrecognizedOptions()>>>.
    When you call this method, then any unrecognized options handed to <<<parse()>>> are
    treated as non-option arguments, rather than causing an exception to be raised.

+----------------------------------------------------------------------------------------
@UNRECOGNIZED_OPTIONS_ALLOWED_EXAMPLE@
+----------------------------------------------------------------------------------------