NAME
    Perinci::CmdLine - Rinci/Riap-based command-line application framework

VERSION
    version 0.98

SYNOPSIS
    In your command-line script:

     #!/usr/bin/perl
     use 5.010;
     use Log::Any '$log';
     use Perinci::CmdLine;

     our %SPEC;
     $SPEC{foo} = {
         v => 1.1,
         summary => 'Does foo to your computer',
         args => {
             bar => {
                 summary=>'Barrr',
                 req=>1,
                 schema=>['str*', {in=>[qw/aa bb cc/]}],
             },
             baz => {
                 summary=>'Bazzz',
                 schema=>'str',
             },
         },
     };
     sub foo {
         my %args = @_;
         $log->debugf("Arguments are %s", \%args);
         [200, "OK", $args{bar} . ($args{baz} ? "and $args{baz}" : "")];
     }

     Perinci::CmdLine->new(url => '/main/foo')->run;

    To run this program:

     % foo --help ;# display help message
     % LANG=id_ID foo --help ;# display help message in Indonesian
     % foo --version ;# display version
     % foo --bar aa ;# run function and display the result
     % foo --bar aa --debug ;# turn on debug output
     % foo --baz x  ;# fail because required argument 'bar' not specified

    To do bash tab completion:

     % complete -C foo foo ;# can be put in ~/.bashrc
     % foo <tab> ;# completes to --help, --version, --bar, --baz and others
     % foo --b<tab> ;# completes to --bar and --baz
     % foo --bar <tab> ;# completes to aa, bb, cc

    See also the peri-run script which provides a command-line interface for
    Perinci::CmdLine.

DESCRIPTION
    Perinci::CmdLine is a command-line application framework. It parses
    command-line options and dispatches to one of your specified Perl
    functions, passing the command-line options and arguments to the
    function. It accesses functions via Riap protocol (using the
    Perinci::Access Riap client library) so you can access remote functions
    transparently. It utilizes Rinci metadata in the code so the amount of
    plumbing that you have to do is quite minimal. Basically most of the
    time you just need to write your "business logic" in your function
    (along with some metadata), and with a couple or several lines of script
    you have created a command-line interface with the following features:

    *   Command-line options parsing

        Non-scalar arguments (array, hash, other nested) can also be passed
        as JSON or YAML. For example, if the "tags" argument is defined as
        'array', then all of below are equivalent:

         % mycmd --tags-yaml '[foo, bar, baz]'
         % mycmd --tags-yaml '["foo","bar","baz"]'
         % mycmd --tags foo --tags bar --tags baz

    *   Help message (utilizing information from metadata, supports
        translation)

         % mycmd --help
         % mycmd -h
         % mycmd -?

    *   Tab completion for bash (including completion from remote code)

         % complete -C mycmd mycmd
         % mycmd --he<tab> ; # --help
         % mycmd s<tab>    ; # sub1, sub2, sub3 (if those are the specified subcommands)
         % mycmd sub1 -<tab> ; # list the options available for sub1 subcommand

        Support for other shell might be added in the future upon request.

    *   Undo/redo/history

        If the function supports transaction (see Rinci::Transaction,
        Riap::Transaction) the framework will setup transaction and provide
        command to do undo (--undo) and redo (--redo) as well as seeing the
        undo/transaction list (--history) and clearing the list
        (--clear-history).

    *   Version (--version, -v)

    *   List available subcommands (--list, -l)

    *   Configurable output format (--format, --format-options)

        By default "yaml", "json", "text", "text-simple", "text-pretty" are
        recognized.

    Note that the each of the above command-line options ("--help",
    "--version", etc) can be renamed or disabled.

    This module uses Log::Any and Log::Any::App for logging. This module
    uses Moo for OO.

DISPATCHING
    Below is the description of how the framework determines what action and
    which function to call. (Currently lots of internal attributes are
    accessed directly, this might be rectified in the future.)

    Actions. The "_actions" attribute is an array which contains the list of
    potential actions to choose, in order. It will then be filled out
    according to the command-line options specified. For example, if
    "--help" is specified, "help" action is shifted to the beginning of
    "_actions". Likewise for "--list", etc. Finally, the "subcommand" action
    (which means an action to call our function) is added to this list.
    After we are finished filling out the "_actions" array, the first action
    is chosen by running a method called "run_<ACTION>". For example if the
    chosen action is "help", "run_help()" is called. These "run_*" methods
    must execute the action, display the output, and return an exit code.
    Program will end with this exit code. A "run_*" method can choose to
    decline handling the action by returning undef, in which case the next
    action will be tried, and so on until a defined exit code is returned.

    The subcommand action and determining which subcommand (function) to
    call. The "subcommand" action (implemented by "run_subcommand()") is the
    one that actually does the real job, calling the function and displaying
    its result. The "_subcommand" attribute stores information on the
    subcommand to run, including its Riap URL. If there are subcommands,
    e.g.:

     my $cmd = Perinci::CmdLine->new(
         subcommands => {
             sub1 => {
                 url => '/MyApp/func1',
             },
             sub2 => {
                 url => '/MyApp/func2',
             },
         },
     );

    then which subcommand to run is determined by the command-line argument,
    e.g.:

     % myapp sub1 ...

    then "_subcommand" attribute will contain "{url=>'/MyApp/func1'}". When
    no subcommand is specified on the command line, "run_subcommand()" will
    decline handling the action and returning undef, and the next action
    e.g. "help" will be executed. But if "default_subcommand" attribute is
    set, "run_subcommand()" will run the default subcommand instead.

    When there are no subcommands, e.g.:

     my $cmd = Perinci::CmdLine->new(url => '/MyApp/func');

    "_subcommand" will simply contain "{url=>'/MyApp/func'}".

    "run_subcommand()" will call the function specified in the "url" in the
    "_subcommand" using "Perinci::Access". (Actually, "run_help()" or
    "run_completion()" can be called instead, depending on which action to
    run.)

LOGGING
    Logging is done with Log::Any (for producing) and Log::Any::App (for
    displaying to outputs). Loading Log::Any::App will add to startup
    overhead time, so this module tries to be smart when determining whether
    or not to do logging output (i.e. whether or not to load Log::Any::App).
    Here are the order of rules being used:

    *   If running shell completion ("COMP_LINE" is defined), output is off

        Normally, shell completion does not need to show log output.

    *   If LOG environment is defined, use that

        You can make a command-line program start a bit faster if you use
        LOG=0.

    *   If subcommand's log_any_app setting is defined, use that

        This allows you, e.g. to turn off logging by default for subcommands
        that need faster startup time. You can still turn on logging for
        those subcommands by LOG=1.

    *   If action metadata's default_log setting is defined, use that

        For example, actions like "help", "list", and "version" has
        "default_log" set to 0, for faster startup time. You can still turn
        on logging for those actions by LOG=1.

    *   Use log_any_app attribute setting

UTF8 OUTPUT
    By default, "binmode(STDOUT, ":utf8")" is issued if utf8 output is
    desired. This is determined by, in order:

    *   Use setting from environment UTF8, if defined.

        This allows you to force-disable or force-enable utf8 output.

    *   Use setting from action metadata, if defined.

        Some actions like help, list, and version output translated text, so
        they have their "use_utf8" metadata set to 1.

    *   Use setting from subcommand, if defined.

    *   Use setting from "use_utf8" attribute.

        This attribute comes from SHARYANTO::Role::TermAttrs, its default is
        determined from UTF8 environment as well as terminal's capabilities.

COLOR THEMES
    By default colors are used, but if terminal is detected as not having
    color support, they are turned off. You can also turn off colors by
    setting COLOR=0 or using PERINCI_CMDLINE_COLOR_THEME=Default::no_color.

COMMAND-LINE OPTION/ARGUMENT PARSING
    This section describes how Perinci::CmdLine parses command-line
    options/arguments into function arguments. Command-line option parsing
    is implemented by Perinci::Sub::GetArgs::Argv.

    For boolean function arguments, use "--arg" to set "arg" to true (1),
    and "--noarg" to set "arg" to false (0). A flag argument ("[bool =>
    {is=>1}]") only recognizes "--arg" and not "--noarg". For single letter
    arguments, only "-X" is recognized, not "--X" nor "--noX".

    For string and number function arguments, use "--arg VALUE" or
    "--arg=VALUE" (or "-X VALUE" for single letter arguments) to set
    argument value. Other scalar arguments use the same way, except that
    some parsing will be done (e.g. for date type, --arg 1343920342 or --arg
    '2012-07-31' can be used to set a date value, which will be a DateTime
    object.) (Note that date parsing will be done by Data::Sah and currently
    not implemented yet.)

    For arguments with type array of scalar, a series of "--arg VALUE" is
    accepted, a la Getopt::Long:

     --tags tag1 --tags tag2 ; # will result in tags => ['tag1', 'tag2']

    For other non-scalar arguments, also use "--arg VALUE" or "--arg=VALUE",
    but VALUE will be attempted to be parsed using JSON, and then YAML. This
    is convenient for common cases:

     --aoa  '[[1],[2],[3]]'  # parsed as JSON
     --hash '{a: 1, b: 2}'   # parsed as YAML

    For explicit JSON parsing, all arguments can also be set via --ARG-json.
    This can be used to input undefined value in scalars, or setting array
    value without using repetitive "--arg VALUE":

     --str-json 'null'    # set undef value
     --ary-json '[1,2,3]' # set array value without doing --ary 1 --ary 2 --ary 3
     --ary-json '[]'      # set empty array value

    Likewise for explicit YAML parsing:

     --str-yaml '~'       # set undef value
     --ary-yaml '[a, b]'  # set array value without doing --ary a --ary b
     --ary-yaml '[]'      # set empty array value

BASH COMPLETION
    To do bash completion, first create your script, e.g. "myscript", that
    uses Perinci::CmdLine:

     #!/usr/bin/perl
     use Perinci::CmdLine;
     Perinci::CmdLine->new(...)->run;

    then execute this in "bash" (or put it in bash startup files like
    "/etc/bash.bashrc" or "~/.bashrc" for future sessions):

     % complete -C myscript myscript; # myscript must be in PATH

PROGRESS INDICATOR
    For functions that express that they do progress updating (by setting
    their "progress" feature to true), Perinci::CmdLine will setup an
    output, currently either Progress::Any::Output::TermProgressBar if
    program runs interactively, or Progress::Any::Output::LogAny if program
    doesn't run interactively.

ATTRIBUTES
  program_name => STR (default from $0)
  use_utf8 => BOOL
    From SHARYANTO::Role::TermAttrs (please see its docs for more details).
    There are several other attributes added by the role.

  url => STR
    Required if you only want to run one function. URL should point to a
    function entity.

    Alternatively you can provide multiple functions from which the user can
    select using the first argument (see subcommands).

  summary => STR
    If unset, will be retrieved from function metadata when needed.

  action_metadata => HASH
    Contains a list of known actions and their metadata. Keys should be
    action names, values should be metadata. Metadata is a hash containing
    these keys:

    *   default_log => BOOL (optional)

        Whether to enable logging by default (Log::Any::App) when "LOG"
        environment variable is not set. To speed up program startup,
        logging is by default turned off for simple actions like "help",
        "list", "version".

    *   use_utf8 => BOOL (optional)

        Whether to issue "binmode(STDOUT, ":utf8")". See "UTF8 OUTPUT" for
        more details.

  subcommands => {NAME => {ARGUMENT=>...}, ...} | CODEREF
    Should be a hash of subcommand specifications or a coderef.

    Each subcommand specification is also a hash(ref) and should contain
    these keys:

    *   "url" (str, required)

        Location of function (accessed via Riap).

    *   "summary" (str, optional)

        Will be retrieved from function metadata at "url" if unset

    *   "description" (str, optional)

        Shown in verbose help message, if description from function metadata
        is unset.

    *   "tags" (array of str, optional)

        For grouping or categorizing subcommands, e.g. when displaying list
        of subcommands.

    *   "log_any_app" (bool, optional)

        Whether to load Log::Any::App, default is true. For subcommands that
        need fast startup you can try turning this off for said subcommands.
        See "LOGGING" for more details.

    *   "use_utf8" (bool, optional)

        Whether to issue "binmode(STDOUT, ":utf8")". See "LOGGING" for more
        details.

    *   "undo" (bool, optional)

        Can be set to 0 to disable transaction for this subcommand; this is
        only relevant when "undo" attribute is set to true.

    *   "show_in_help" (bool, optional, default 1)

        If you have lots of subcommands, and want to show only some of them
        in --help message, set this to 0 for subcommands that you do not
        want to show.

    *   "pass_cmdline_object" (bool, optional, default 0)

        To override "pass_cmdline_object" attribute on a per-subcommand
        basis.

    *   "args" (hash, optional)

        If specified, will send the arguments (as well as arguments
        specified via the command-line). This can be useful for a function
        that serves more than one subcommand, e.g.:

         subcommands => {
             sub1 => {
                 summary => 'Subcommand one',
                 url     => '/some/func',
                 args    => {flag=>'one'},
             },
             sub2 => {
                 summary => 'Subcommand two',
                 url     => '/some/func',
                 args    => {flag=>'two'},
             },
         }

        In the example above, both subcommand "sub1" and "sub2" point to
        function at "/some/func". But the function can differentiate between
        the two via the "flag" argument being sent.

         % cmdprog sub1 --foo 1 --bar 2
         % cmdprog sub2 --foo 2

        In the first invocation, function will receive arguments "{foo=>1,
        bar=>2, flag=>'one'}" and for the second: "{foo=>2, flag=>'two'}".

    Subcommands can also be a coderef, for dynamic list of subcommands. The
    coderef will be called as a method with hash arguments. It can be called
    in two cases. First, if called without argument "name" (usually when
    doing --list) it must return a hashref of subcommand specifications. If
    called with argument "name" it must return subcommand specification for
    subcommand with the requested name only.

  default_subcommand => NAME
    If set, subcommand will always be set to this instead of from the first
    argument. To use other subcommands, you will have to use --cmd option.

  common_opts => HASH
    A hash of common options, which are command-line options that are not
    associated with any subcommand. Each option is itself a specification
    hash containing these keys:

    *   category (str)

        Optional, for grouping options in help/usage message, defaults to
        "Common options".

    *   getopt (str)

        Required, for Getopt::Long specification.

    *   handler (code)

        Required, for Getopt::Long specification.

    *   usage (str)

        Optional, displayed in usage line in help/usage text.

    *   summary (str)

        Optional, displayed in description of the option in help/usage text.

    *   show_in_usage (bool or code, default: 1)

        A flag, can be set to 0 if we want to skip showing this option in
        usage in --help, to save some space. The default is to show all,
        except --subcommand when we are executing a subcommand (obviously).

    *   show_in_options (bool or code, default: 1)

        A flag, can be set to 0 if we want to skip showing this option in
        options in --help. The default is to 0 for --help and --version in
        compact help. Or --subcommands, if we are executing a subcommand
        (obviously).

    *   order (int)

        Optional, for ordering. Lower number means higher precedence,
        defaults to 1.

    A partial example from the default set by the framework:

     {
         help => {
             category        => 'Common options',
             getopt          => 'help|h|?',
             usage           => '--help (or -h, -?)',
             handler         => sub { ... },
             order           => 0,
             show_in_options => sub { $ENV{VERBOSE} },
         },
         format => {
             category    => 'Common options',
             getopt      => 'format=s',
             summary     => 'Choose output format, e.g. json, text',
             handler     => sub { ... },
         },
         undo => {
             category => 'Undo options',
             getopt   => 'undo',
             ...
         },
         ...
     }

    The default contains: help (getopt "help|h|?"), version (getopt
    "version|v"), action (getopt "action"), format (getopt "format=s"),
    format_options (getopt "format-options=s"). If there are more than one
    subcommands, this will also be added: list (getopt "list|l"). If dry-run
    is supported by function, there will also be: dry_run (getopt
    "dry-run"). If undo is turned on, there will also be: undo (getopt
    "undo"), redo (getopt "redo"), history (getopt "history"), clear_history
    (getopt "clear-history").

    Sometimes you do not want some options, e.g. to remove "format" and
    "format_options":

     delete $cmd->common_opts->{format};
     delete $cmd->common_opts->{format_options};
     $cmd->run;

    Sometimes you want to rename some command-line options, e.g. to change
    version to use capital "-V" instead of "-v":

     $cmd->common_opts->{version}{getopt} = 'version|V';

    Sometimes you want to add subcommands as common options instead. For
    example:

     $cmd->common_opts->{halt} = {
         category    => 'Server options',
         getopt      => 'halt',
         summary     => 'Halt the server',
         handler     => sub {
             $cmd->{_selected_subcommand} = 'shutdown';
         },
     };

    This will make:

     % cmd --halt

    equivalent to executing the 'shutdown' subcommand:

     % cmd shutdown

  exit => BOOL (default 1)
    If set to 0, instead of exiting with exit(), run() will return the exit
    code instead.

  log_any_app => BOOL (default: 1)
    Whether to load Log::Any::App (enable logging output) by default. See
    "LOGGING" for more details.

  custom_completer => CODEREF
    Will be passed to Perinci::Sub::Complete's "shell_complete_arg()". See
    its documentation for more details.

  custom_arg_completer => CODEREF | {ARGNAME=>CODEREF, ...}
    Will be passed to Perinci::Sub::Complete's "shell_complete_arg()". See
    its documentation for more details.

  pass_cmdline_object => BOOL (optional, default 0)
    Whether to pass special argument "-cmdline" containing the
    Perinci::CmdLine object to function. This can be overriden using the
    "pass_cmdline_object" on a per-subcommand basis.

    Passing the cmdline object can be useful, e.g. to call run_help(), etc.

  pa_args => HASH
    Arguments to pass to Perinci::Access. This is useful for passing e.g.
    HTTP basic authentication to Riap client
    (Perinci::Access::HTTP::Client):

     pa_args => {handler_args => {user=>$USER, password=>$PASS}}

  undo => BOOL (optional, default 0)
    Whether to enable undo/redo functionality. Some things to note if you
    intend to use undo:

    *   These common command-line options will be recognized

        "--undo", "--redo", "--history", "--clear-history".

    *   Transactions will be used

        "use_tx=>1" will be passed to Perinci::Access, which will cause it
        to initialize the transaction manager. Riap requests begin_tx and
        commit_tx will enclose the call request to function.

    *   Called function will need to support transaction and undo

        Function which does not meet qualifications will refuse to be
        called.

        Exception is when subcommand is specified with "undo=>0", where
        transaction will not be used for that subcommand. For an example of
        disabling transaction for some subcommands, see "bin/u-trash" in the
        distribution.

  undo_dir => STR (optional, default ~/.<program_name>/.undo)
    Where to put undo data. This is actually the transaction manager's data
    dir.

METHODS
  new(%opts) => OBJ
    Create an instance.

  run() -> INT
    The main routine. Its job is to parse command-line options in @ARGV and
    determine which action method (e.g. run_subcommand(), run_help(), etc)
    to run. Action method should return an integer containing exit code. If
    action method returns undef, the next action candidate method will be
    tried.

    After that, exit() will be called with the exit code from the action
    method (or, if "exit" attribute is set to false, routine will return
    with exit code instead).

METADATA PROPERTY ATTRIBUTE
    This module observes the following Rinci metadata property attributes:

  x.perinci.cmdline.default_format => STR
    Set default output format (if user does not specify via --format
    command-line option).

RESULT METADATA
    This module interprets the following result metadata keys:

  is_stream => BOOL
    XXX should perhaps be defined as standard in Rinci::function.

    If set to 1, signify that result is a stream. Result must be a glob, or
    an object that responds to getline() and eof() (like a Perl IO::Handle
    object), or an array/tied array. Format must currently be "text"
    (streaming YAML might be supported in the future). Items of result will
    be displayed to output as soon as it is retrieved, and unlike
    non-streams, it can be infinite.

    An example function:

     $SPEC{cat_file} = { ... };
     sub cat_file {
         my %args = @_;
         open my($fh), "<", $args{path} or return [500, "Can't open file: $!"];
         [200, "OK", $fh, {is_stream=>1}];
     }

    another example:

     use Tie::Simple;
     $SPEC{uc_file} = { ... };
     sub uc_file {
         my %args = @_;
         open my($fh), "<", $args{path} or return [500, "Can't open file: $!"];
         my @ary;
         tie @ary, "Tie::Simple", undef,
             SHIFT     => sub { eof($fh) ? undef : uc(~~<$fh> // "") },
             FETCHSIZE => sub { eof($fh) ? 0 : 1 };
         [200, "OK", \@ary, {is_stream=>1}];
     }

    See also Data::Unixish and App::dux which deals with streams.

  cmdline.display_result => BOOL
    If you don't want to display function output (for example, function
    output is a detailed data structure which might not be important for end
    users), you can set "cmdline.display_result" result metadata to false.
    Example:

     $SPEC{foo} = { ... };
     sub foo {
         ...
         [200, "OK", $data, {"cmdline.display_result"=>0}];
     }

  cmdline.page_result => BOOL
    If you want to filter the result through pager (currently defaults to
    $ENV{PAGER} or "less -FRSX"), you can set "cmdline.page_result" in
    result metadata to true.

    For example:

     $SPEC{doc} = { ... };
     sub doc {
         ...
         [200, "OK", $doc, {"cmdline.page_result"=>1}];
     }

  cmdline.pager => STR
    Instruct Perinci::CmdLine to use specified pager instead of $ENV{PAGER}
    or the default "less" or "more".

  cmdline.exit_code => INT
    Instruct Perinci::CmdLine to use this exit code, instead of using
    (function status - 300).

ENVIRONMENT
    *   PERINCI_CMDLINE_PROGRAM_NAME => STR

        Can be used to set CLI program name.

    *   PERINCI_CMDLINE_COLOR_THEME => STR

        Can be used to set "color_theme".

    *   PROGRESS => BOOL

        Explicitly turn the progress bar on/off.

    *   PAGER => STR

        Like in other programs, can be set to select the pager program (when
        "cmdline.page_result" result metadata is active). Can also be set to
        '' or 0 to explicitly disable paging even though "cmd.page_result"
        result metadata is active.

    *   COLOR => INT

        Please see SHARYANTO::Role::TermAttrs.

    *   UTF8 => BOOL

        Please see SHARYANTO::Role::TermAttrs.

FAQ
  How do I debug my program?
    You can set environment DEBUG=1 or TRACE=1. See Log::Any::App for more
    details.

  How does Perinci::CmdLine compare with other CLI-app frameworks?
    The main difference is that Perinci::CmdLine accesses your code through
    Riap protocol, not directly. This means that aside from local Perl code,
    Perinci::CmdLine can also provide CLI for code in remote
    hosts/languages. For a very rough demo, download and run this PHP
    Riap::TCP server
    https://github.com/sharyanto/php-Phinci/blob/master/demo/phi-tcpserve-te
    rbilang.php on your system. After that, try running:

     % peri-run riap+tcp://localhost:9090/terbilang --help
     % peri-run riap+tcp://localhost:9090/terbilang 1234

    Everything from help message, calling, argument checking, tab completion
    works for remote code as well as local Perl code.

  How to add support for new output format (e.g. XML, HTML)?
    See Perinci::Result::Format.

  My function has argument named 'format', but it is blocked by common option '--format'!
    To add/remove/rename common options, see the documentation on
    "common_opts" attribute. In this case, you want:

     delete $cmd->common_opts->{format};
     #delete $cmd->common_opts->{format_options}; # you might also want this

    or perhaps rename it:

     $cmd->common_opts->{output_format} = $cmd->common_opts->{format};
     delete $cmd->common_opts->{format};

  How to accept input from STDIN (or files)?
    If you specify 'cmdline_src' to 'stdin' to a 'str' argument, the
    argument's value will be retrieved from standard input if not specified.
    Example:

     use Perinci::CmdLine;
     $SPEC{cmd} = {
         v => 1.1,
         args => {
             arg => {
                 schema => 'str*',
                 cmdline_src => 'stdin',
             },
         },
     };
     sub cmd {
         my %args = @_;
         [200, "OK", "arg is '$args{arg}'"];
     }
     Perinci::CmdLine->new(url=>'/main/cmd')->run;

    When run from command line:

     % cat file.txt
     This is content of file.txt
     % cat file.txt | cmd
     arg is 'This is content of file.txt'

    If your function argument is an array, array of lines will be provided
    to your function. A mechanism to be will be provided in the future
    (currently not yet specified in Rinci::function specification).

  But I don't want the whole file content slurped into string/array, I want streaming!
    If your function argument is of type "stream" or "filehandle", an I/O
    handle will be provided to your function instead. But this part is not
    implemented yet.

    Currently, see App::dux for an example on how to accomplish this on
    function argument of type "array". Basically in App::dux, you feed an
    array tied with Tie::Diamond as a function argument. Thus you can get
    lines from file/STDIN iteratively with each().

  My function has some cmdline_aliases or cmdline_src defined but I want to change it!
    For example, your "f1" function metadata might look like this:

     package Package::F1;
     our %SPEC;
     $SPEC{f1} = {
         v => 1.1,
         args => {
             foo => {
                 cmdline_aliases => { f=> {} },
             },
             bar => { ... },
             fee => { ... },
         },
     };
     sub f1 { ... }
     1;

    And your command-line script "f1":

     #!perl
     use Perinci::CmdLine;
     Perinci::CmdLine->new(url => '/Package/F1/f1')->run;

    Now you want to create a command-line script interface for this
    function, but with "-f" as an alias for "--fee" instead of "--foo". This
    is best done by modifying the metadata and creating a wrapper function
    to do this, e.g. your command-line script "f1" becomes:

     package main;
     use Perinci::CmdLine;
     use Package::F1;
     use Data::Clone;
     our %SPEC;
     $SPEC{f1} = clone $Package::F1::SPEC{f1};
     delete $SPEC{f1}{args}{foo}{cmdline_aliases};
     $SPEC{f1}{args}{fee}{cmdline_aliases} = {f=>{}};
     *f1 = \&Package::F1::f1;
     Perinci::CmdLine->new(url => '/main/f1')->run;

    This also demonstrates the convenience of having the metadata as a data
    structure: you can manipulate it however you want.

  How to do custom completion for my argument?
    By default, Perinci::Sub::Complete's "complete_arg_val()" can employ
    some heuristics to complete argument values, e.g. from the "in" clause
    or "max" and "min":

     $SPEC{set_ticket_status} = {
         v => 1.1,
         args => {
             ticket_id => { ... },
             status => {
                 schema => ['str*', in => [qw/new open stalled resolved rejected/],
             },
         },
     }

    But if you want to supply custom completion, the Rinci::function
    specification allows specifying a "completion" property for your
    argument, for example:

     use Perinci::Sub::Complete qw(complete_array);
     $SPEC{del_user} = {
         v => 1.1,
         args => {
             username => {
                 schema => 'str*',
                 req => 1,
                 pos => 0,
                 completion => sub {
                     my %args = @_;

                     # get list of users from database or whatever
                     my @users = ...;
                     complete_array(array=>\@users, word=>$args{word});
                 },
             },
             ...
         },
     };

    You can use completion your command-line program:

     % del-user --username <tab>
     % del-user <tab> ; # since the 'username' argument has pos=0

  My custom completion does not work, how do I debug it?
    Completion works by the shell invoking our (the same) program with
    "COMP_LINE" and "COMP_POINT" environment variables. You can do something
    like this to see debugging information:

     % COMP_LINE='myprog --arg x' COMP_POINT=13 PERL5OPT=-MLog::Any::App TRACE=1 myprog --arg x

  My application is OO?
    This framework is currently non-OO and function-centric. There are
    already several OO-based command-line frameworks on CPAN.

TODOS
    "cmdline_src" argument specification has not been fully implemented:
    Providing I/O handle for argument of type "stream"/"filehandle".

SEE ALSO
    Perinci, Rinci, Riap.

    Other CPAN modules to write command-line applications: App::Cmd,
    App::Rad, MooseX::Getopt.

HOMEPAGE
    Please visit the project's homepage at
    <https://metacpan.org/release/Perinci-CmdLine>.

SOURCE
    Source repository is at
    <https://github.com/sharyanto/perl-Perinci-CmdLine>.

BUGS
    Please report any bugs or feature requests on the bugtracker website
    <https://rt.cpan.org/Public/Dist/Display.html?Name=Perinci-CmdLine>

    When submitting a bug or request, please include a test-file or a patch
    to an existing test-file that illustrates the bug or desired feature.

AUTHOR
    Steven Haryanto <stevenharyanto@gmail.com>

COPYRIGHT AND LICENSE
    This software is copyright (c) 2013 by Steven Haryanto.

    This is free software; you can redistribute it and/or modify it under
    the same terms as the Perl 5 programming language system itself.

