Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Getopt::TooMany: looking for a perfect CLI processor

by Dallaylaen (Chaplain)
on Sep 06, 2019 at 21:54 UTC ( #11105749=perlquestion: print w/replies, xml ) Need Help??

Dallaylaen has asked for the wisdom of the Perl Monks concerning the following question:

Hello dear esteemed monks,

While Getopt::Long is a great module, I started noticing it lacks some features, like help generation or ability to stop processing arguments on first non-option. So I looked at cpan search for "getopt" at and I'm overwhelmed by the number of modules that are already there.

What I would like to get is (apart from just "processing the command line the way Getop::Long does"):

1. Generating help on the fly (Getopt::Helpful does that but seems unmaintaned);

2. Object-oriented interface via instantiation and accessors/mutators, not inheritance:

my $cli = Getopt::Something->new( "Usage: $0 [options] <file> ...", [ "x|expect=s", \@except, "<pattern> Add an exception" ], ... ); $cli->stop_on_argument( 1|0 ); $cli->run(); # or $cli->run( \@array ); if not @ARGV

3. I would love to add any other features I find missing.

So what are the latest and greatest members of Getopt:: Family? Thank you.

Replies are listed 'Best First'.
Re: Getopt::TooMany: looking for a perfect CLI processor
by stevieb (Canon) on Sep 06, 2019 at 22:15 UTC
      Haven't seen this one, thank you.
Re: Getopt::TooMany: looking for a perfect CLI processor
by swl (Parson) on Sep 07, 2019 at 00:32 UTC
      Well, it does answer my question as a whole. Thank you.
Re: Getopt::TooMany: looking for a perfect CLI processor
by rjt (Curate) on Sep 07, 2019 at 08:27 UTC

    For help generation and better error handling, Pod::Usage has been in my toolbox for a long time. It will pull the help right from your perldoc POD. (Which you were hopefully going to write anyway, so it's no extra work.) It is configurable as to which sections it will pull and display when help is needed.

    Your point #2 has me confused. Why is that important, as long as the interface is well designed and documented?

    Point #3, there are indeed a lot of features from Pod::Usage and the plethora of Getopt:: modules you've seen. None that I know you need though. (And none that I use on a regular basis.)

      I don't know, somehow I prefer to have option descriptions close to the declarations. A POD is (hopefully) a comprehensive manual with detailed explanations, whereas --help is just a quick reminder for those who can't keep all the options in their head. Maybe I'm wrong and will change my mind later.

      #2 is merely avoiding namespace pollution (via lots of exported functions - easy to forget or hit a collision), @ISA clutter (when one has to extend a Getopt:: class - I've seen that a couple times on CPAN), and awkward syntax (local $Foo::Bar::VariableName = $Foo::Bar::VariableName + 1 is a cool feature, but let's use it when it's needed).

      Oh and thanks for mentioning Pod::Usage, I didn't know of that one.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://11105749]
Approved by davies
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (2)
As of 2023-05-29 01:32 GMT
Find Nodes?
    Voting Booth?

    No recent polls found