Is PCLI possible?
At the French Perl Workshop (and probably elsewhere before), Matt Trout talked about why and how some ideas could succeed and most other fail. An interesting talk. The last part was a rant against the numerous modules on the CPAN to parse command-line options. His proposal was to do the same thing to command-line programs (CLI) than PSGI did to web applications: formulate a generic specification, that developers can use to build applications and not depend on a specific implementation.
A very interesting idea. We were a few (BooK, cmaussan, niels and myself) to begin thinking about what this PCLI specification could look like. I wrote down on paper what I've been doing in the numerous CLI programs (for a broad value of the terms) I wrote over the past years.
A CLI program has to go through these steps:
- fetch and parse environment variables (
%ENV); errors may be warned about or fatal
- fetch and parse command-line options (
@ARGV); errors are fatal
- handle usage and help (
- parse configuration file; errors are fatal
- check all parameters (mandatory options, exclusive options, etc); errors are fatal
- apply all parameters default values
- setup logging; errors may be silent, warned about, or fatal
- become a daemon, for the programs intended to run this way
- setup basic signals managements (
HUP), usually for daemons, but can also be useful for programs running for a long time
Now, I didn't know what PSGI looked like (I'm a sysdev, not a webdev). Today, I read the specification, and it confirmed what I had already identified: yes, PSGI is brilliantly "simple" because it was written by people knowing very well this field, helping themselves with the experience of similar specifications (WSGI, Rack, JSGI). But it is also simple because it is a protocol built on top of a protocol (HTTP), built on top of a protocol (TCP), built... At PSGI level, there's just a bidirectional channel with data going in both directions. And it's platform agnostic.
However, in the CLI world (and let's limit ourselves to the Unix world for the sake of simplicity), we have multiple channels of input (
%ENV, options, configuration file(s),
STDIN, input data files, signals) and output (
STDERR, logging, output data files), and no standardized protocol of any kind.
Now, I'm afraid that either we try to cover most of the features we need, and we end up with a specification too complex, or we limit to a subset of the features, and we end up with a specification too simple to be actually useful.
Did I miss something? Was Matt too optimistic or am I once again too pessimistic?