I’m starting a (potentially long, hopefully once daily) series of blog posts about Perinci::CmdLine, my library for creating command-line application in Perl, and issues on command-line applications in general. Since I want to only spend between 10-30 minutes writing each post, I expect each post to be short and a single topic, if large enough, might span several posts. I was inspired by byterock’s series of posts last year where he chronicled his adventure with Moose (and then with XS, in another series), as well as Louis Erickson‘s series on the Perl Best Practices. The decision to do 10-30 minutes per daily post was first made last December when I did an advent calendar. I found that that amount of time spent per post is about right because it does not disrupt my daily flow too much. If I have a longer block of time available, e.g. 1-2 hours, I can always create several posts and schedule them to be published in the subsequent days, giving me more time to come up with the idea for the next unwritten post.
The series will begin with a list of features that I need/want in a command-line application library, and a review of other libraries/frameworks available on CPAN and in other languages and what’s “wrong” (and “right”) about each of them, and why I ended up creating my own.
After that, the next posts will continue with the background and architecture of Perinci::CmdLine itself. And finally with building a (or several) command-line applications step by step, highlighting related features of Perinci::CmdLine as we go along.
Requirements
Ok, enough introduction. Let’s enumerate all the features that I need for a command-line application library. Ideally, for me at least, I want as many as needed features as possible, to allow my to just write the “business logic” and not deal with all the mundane, tedious plumbing tasks.
A typical command-line application (hereby called a CLI app for short, while the library will be called CLI library) needs to do these things:
- parse command-line options and arguments
- decide which code to handle which tasks (routing)
- display usage/help message (typically invoked via --help, -h, or -?)
- display result/output
- return appropriate exit code
Also:
- A CLI app should have a proper manpage.
- Sometimes a CLI app wants to be interactive and prompts/asks user question.
- Often we also want to display progress indicator for visual hints to user, if we are doing something that might take a long time.
- Specific to a CLI app, we also want tab completion.
- And lastly, we want fast startup time. I define fast as under 0.05-0.1s, because anything over that starts to get noticeable.
In the next post we’ll discuss Getopt::Long.
perlancar's blog 