Perinc...Manual(3pm)

🌸 NAME 🌸

Perinci::CmdLine::Manual β€” it's, like, the whole entire manual for Perinci::CmdLine. The manual manual. Bestie you're gonna be so good at CLIs after this. πŸ’–

πŸŽ€ VERSION πŸŽ€

This doc describes version 2.000.2 of Perinci::CmdLine::Manual (from Perl distribution Perinci-CmdLine), released on 2026-03-30. No cap, that's the real date. πŸ’…

✨ DESCRIPTION ✨

Okay so here's the whole rundown, section by section, and I'm not skipping a single crumb.


πŸ“š List Of Documents Included In This Distribution πŸ“š

These are the PODs that live in this distribution, bestie:

  • Perinci::CmdLine::Manual
  • Perinci::CmdLine::Manual::Explanation::ArgumentValidation
  • Perinci::CmdLine::Manual::FAQ
  • Perinci::CmdLine::Manual::HowTo::99Examples
  • Perinci::CmdLine::Manual::HowTo::Completion
  • Perinci::CmdLine::Manual::HowTo::Debugging

🧠 About This Manual 🧠

This manual is organized using the documentation structure described in [1], where every doc gets sorted into one of four types. Think of it like a four-way vibe check for documentation:

  • TUTORIAL β€” learning-oriented 🌱
    • goal: allow a newcomer to get started
    • form: lessons
    • analogy: teaching a child to cook
  • HOW-TO GUIDE β€” problem-oriented πŸ”§
    • goal: show how to solve a specific problem
    • form: a series of steps
    • analogy: a recipe in a cookery book
  • EXPLANATION β€” understanding-oriented πŸ’­
    • goal: explain
    • form: a discursive explanation
    • analogy: an article on culinary social history
  • REFERENCE β€” information-oriented πŸ“–
    • goal: describe the machinery
    • form: a dry description
    • analogy: a reference encyclopedia article

And the whole thing is split down the middle: the left side (the tutorials and the explanations) is most useful when we're studying, while the right side (the how-to guides and the reference) is most useful when we're working. Two moods, one manual. Periodt.

[1] https://docs.divio.com/documentation-system/

Lowkey important: a lot of the existing documentation is still not migrated to the above system. So not everything obeys the four-type girlie hierarchy yet. πŸ™ˆ

πŸ‘‘ About Perinci::CmdLine πŸ‘‘

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 that function. It accesses functions via Riap protocol (using the Perinci::Access Riap client library), so you can use remote functions transparently. Remote besties are still besties, fr fr.

Here's the feature list, and it ate:

  • 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 the below are equivalent:
% mycmd --tags-yaml '[foo, bar, baz]'
% mycmd --tags-json '["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 various shells (including completion from remote code) 🐚
    • Example for bash:
% 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
  • 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 (--subcommands) πŸ“‹
  • Configurable output format (--format, --format-options) 🎨
    • By default yaml, json, text, text-simple, text-pretty are recognized.

πŸ¦‹ Concepts πŸ¦‹

Perinci::CmdLine is very function-oriented (and not object-oriented, on purpose). You write your "business logic" in a function β€” of course, you are free to subdivide or delegate to other functions, but there must be one main function for a single-subcommand CLI application, or one function for each subcommand in a multiple-subcommand CLI application.

 sub cliapp {
     ...
 }

Then you annotate the function with Rinci metadata, where you describe what arguments (and command-line aliases, if any) the function (program) accepts, the summary and description of those arguments, and several other aspects as necessary.

 $SPEC{cliapp} = {
     v => 1.1,
     summary => 'A program to do blah blah',
     args => {
         foo => {
             summary => 'foo argument',
             req => 1,
             pos => 0,
             cmdline_aliases => {f=>{}},
         },
         bar => { ... },
     },
 };
 sub cliapp {
     ...
 }

And finally β€” the moment we've all been waiting for β€” you "run" your function:

 use Perinci::CmdLine::Any;
 Perinci::CmdLine::Any->new(url => '/main/cliapp')->run;

For a multi-subcommand application:

 Perinci::CmdLine::Any->new(
     url => '/main/cliapp',
     subcommands => {
         sc1 => { url => '/main/do_sc1' },
         sc2 => { url => '/main/do_sc2' },
         ...
     },
 )->run;

That's it. That's the whole thing. Command-line option parsing, help message, as well as tab completion will work without extra effort. It's giving main character energy for your terminal. ✨

And to run a remote function, you can simply specify a remote URL, e.g. http://example.com/api/somefunc. All the features like options parsing, help/usage, as well as tab completion will work with remote functions as well. πŸ’«


🌈 Logging 🌈

Logging is done with Log::ger (for producing). For displaying logs, Log::ger::App is used.

Initializing logging adds a bit to startup overhead time, so the framework defaults to no logging. To turn on logging from the code, set the log attribute to true when constructing a Perinci::CmdLine object. Or, use something like:

 % PERL5OPT=-MLog::ger::App TRACE=1 yourcli.pl

πŸ“ Configuration File πŸ“

Configuration files are read to preset the value of arguments, before potentially overridden/merged with command-line options. Configuration files are in IOD format, which is basically INI with some extra features. INI but make it extra. πŸ’…

By default, configuration files are searched in home directory then /etc, with the name of program_name + .conf. If multiple files are found, the contents are merged together.

If a user wants to use a custom configuration file, she can issue --config-path command-line option.

If a user does not want to read a configuration file, she can issue --no-config command-line option.

INI files have the concept of "sections". In Perinci::CmdLine, you can use sections to put settings that will only be applied to a certain subcommand, or a certain "profile", or other conditions. "Config profiles" is a way to specify multiple sets/cases/scenarios in a single configuration file.

Example 1 (without any profile or subcommand):

 ; prog.conf

 foo=1
 bar=2

When executing program (the comments will show what arguments are set):

 % prog; # {foo=>1, bar=>2}
 % prog --foo 10; # {foo=>10, bar=>2}

Example 2 (with profiles):

 ; prog.conf

 [profile=profile1]
 foo=1
 bar=2

 [profile=profile2]
 foo=10
 bar=20

When executing program:

 % prog; # {}
 % prog --config-profile profile1; # {foo=>1, bar=>2}
 % prog --config-profile profile2; # {foo=>10, bar=>20}

Example 3 (with subcommands):

 ; prog.conf

 [subcommand=sc1]
 foo=1
 bar=2

 [subcommand=sc2]
 baz=3
 qux=4

When executing program:

 % prog sc1; # {foo=>1, bar=>2}
 % prog sc2; # {baz=>3, qux=>4}

Example 4 (with subcommands and profiles):

 ; prog.conf
 [subcommand=sc1 profile=profile1]
 foo=1
 bar=2

 [profile=profile2 subcommand=sc1]
 foo=10
 bar=20

When executing program:

 % prog sc1 --config-profile profile1; # {foo=>1, bar=>2}
 % prog sc1 --config-profile profile2; # {foo=>10, bar=>20}

πŸ’… 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. (Yes, that's a mouthful, we love her anyway. 🫢)

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. Slight chaos, but it's the rules. πŸ’€

For string and number function arguments, use --arg VALUE or --arg=VALUE (or -X VALUE for single letter arguments) to set the 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

Submetadata. Arguments from submetadata will also be given respective command-line options (and aliases) with prefixed names. For example this function metadata:

        {
            v => 1.1,
            args => {
                foo => {schema=>'str*'},
                bar => {
                    schema => 'hash*',
                    meta => {
                        v => 1.1,
                        args => {
                            baz => {schema=>'str*'},
                            qux => {
                                schema=>'str*,
                            },
                        },
                    },
                },
                quux => {
                    schema => 'array*',
                    element_meta => {
                        v => 1.1,
                        args => {
                            corge => {schema=>'str*', cmdline_aliases=>{C=>{}},
                            grault => {schema=>'str*'},
                        },
                    },
                },
            },
        }

so like, you can specify on the command-line:

% prog --foo val \
    --bar-baz val --bar-qux val \
    --quux-corge 11 \
    --quux-corge 21 --quux-grault 22 \
    --quux-C 31

and the resulting argument will be literally this:

{
    foo => 'val',
    bar => {
        baz => 'val',
        qux => 'val',
    },
    quux => [
        {corge=>11},
        {corge=>21, grault=>22},
        {corge=>31},
    ],
}

for more examples on argument submetadata, see Perinci::Examples::SubMeta. πŸ’…


✨ Shell Completion ✨

okay so the framework can literally detect when COMP_LINE and COMP_POINT environment variables (set by bash when completing using external command) are set, and then it's like "i got you bestie" and answers the completion. in bash, activating tab completion for your script is as easy as (assuming your script is already in PATH):

% complete -C yourscript yourscript

that is, your script can complete itself (but scripts generated with Perinci::CmdLine::Inline are equipped with companion scripts for completion). the above command can be put in ~/.bashrc. but it is recommended that you use shcompgen instead (see below). πŸ’…

tcsh uses COMMAND_LINE instead. the framework can also detect that.

for other shells: some shells can emulate bash (like zsh) and for some other (like fish) you need to generate a set of complete commands for each command-line option. 🐟

shcompgen is a CLI tool that can detect all scripts in PATH if they are using Perinci::CmdLine (as well as a few other frameworks) and generate shell completion scripts for them. it supports several shells. combined with cpanm-shcompgen, you can install modules and have the shell completion of scripts activated immediately. 🐚✨


✨ 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. πŸ“Š


🏠 HOMEPAGE 🏠

please visit the project's homepage at <https://metacpan.org/release/Perinci-CmdLine>. πŸ’–


πŸ“¦ SOURCE πŸ“¦

source repository is at <https://github.com/perlancar/perl-Perinci-CmdLine>. ✨


πŸ‘€ SEE ALSO πŸ‘€

a list of tutorial posts on my blog, will eventually be moved to POD: <https://perlancar.wordpress.com/category/pericmd-tut/> πŸ“


πŸ‘‘ AUTHOR πŸ‘‘

perlancar <perlancar@cpan.org> πŸ’…


🫢 CONTRIBUTING 🫢

to contribute, you can send patches by email/via RT, or send pull requests on GitHub. 🫢

most of the time, you don't need to build the distribution yourself. you can simply modify the code, then test via:

% prove -l

if you want to build the distribution (e.g. to try to install it locally on your system), you can install Dist::Zilla, Dist::Zilla::PluginBundle::Author::PERLANCAR, Pod::Weaver::PluginBundle::Author::PERLANCAR, and sometimes one or two other Dist::Zilla- and/or Pod::Weaver plugins. any additional steps required beyond that are considered a bug and can be reported to me. πŸ›


this software is copyright (c) 2026 by perlancar <perlancar@cpan.org>.

this is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself. βš–οΈ


🐞 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. πŸ”


and that's a wrap, bestie! this was perl v5.40.1, dated 2026-04-05, from the Perinc...Manual(3pm) page. stay slay! πŸ’–βœ¨

πŸ“¦ where this page comes from