Re: Getopt::Helpful - online help and options
On Mon, 15 Nov 2004, khemir nadim wrote: Chris, Could you please give some info on this. I must say your answer perplexed me and I don't understand what you mean. AppConfig has the ability to read configuration from the program, external .ini-style files, and the command line in a mostly uniform fashion. If you use it in a "use strict" sort of way you define all of the variables and it whines if any are missing. It allows types to be defined in classical getopt style or programatically. If you wanted to do a database lookup to verify a valid command line paramater it "could" be done. This is all very handy IMHO. We passed this paradigm along to one of my clients, the National Weather Service. One of their staff coders/weather doods (Mark Fenbers, cool guy) said "hey, why can't we print usage statements" based off what AppConfig was being told. Given how many options some of their scripts have and new ones being added regularly it was a hassle to maintain the usage output in coordination with the options spec'd and implemented for AppConfig. So I've been working on contacting Andy Lester to see if he'd approve of such a change, but Andy's apparently really slammed so the conversation hasn't made it too far yet. Makes sense now? :) -- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. -Bertrand Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)
Re: Getopt::Helpful - online help and options
Chris, Could you please give some info on this. I must say your answer perplexed me and I don't understand what you mean. Cheers, Nadim. "Christopher Hicks" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Fri, 12 Nov 2004, khemir nadim wrote: > > Hi, I haven't tested your code (will do this week-end) and I think it's a > > good idea. > > Ya ya. We've been talking about extending AppConfig to do something > similar for a while, but no progress yet. > > -- > > > The whole problem with the world is that fools and fanatics are always so > certain of themselves, and wiser people so full of doubts. -Bertrand > Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)
Re: Getopt::Helpful - online help and options
On Fri, 12 Nov 2004, khemir nadim wrote: Hi, I haven't tested your code (will do this week-end) and I think it's a good idea. Ya ya. We've been talking about extending AppConfig to do something similar for a while, but no progress yet. -- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. -Bertrand Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)
Re: Getopt::Helpful - online help and options
# The following was supposedly scribed by # khemir nadim # on Friday 12 November 2004 05:26 am: >lately I have added, to the application, a self search feature that > extract and display information embeded in pod. There are already some modules designed to turn your pod into your options. I opted not to go that route because pod lacks variables (see the previous discussions under "not so plain documentation".) The primary goal here was to handle user-configurable options with reasonable defaults (so, of course the user should be able to see those defaults in the help message (and of course I don't want to duplicate information.)) >I believe it would be good to let the users of you module define > what , how many types and how they want the help. So even my format > is limiting. I'm more inclined to leave that up to 'app -h | less' or 'perldoc app'. But, I guess it depends on how many options you have and how much help is included. That said, I would like to find a way to integrate pod and help more closely. However, I think at some point that the change has to happen in perldoc (say, for instance, a new type of paragraph which instructs perldoc to call the application with a certain flag ($paragraph = `app --podhelp` or something.)) Currently, I have a section in my pods which elaborates on each option (there's a script kicking around here somewhere which does formats help into pod, but I don't like that approach because changes are a pain.) >You could still have some default values and types for the user that > is happy with what comes standard with the module. I'm not sure I'm following you here. You want the help in multiple formats or multiple levels of verbosity? >Searching within the switch help is very usefull and should be > supported. So, --colorize is an option and 'pbs -hs colorize' shows only the help for that option? Well, there is a usage() method in Getopt::Helpful that gets called when you include the '+help' builtin and don't define a main::usage(). I suppose it could check for leftovers in @ARGV and change behavior based on that. Alternatively, there could be a '+helpsearch' builtin which calls a different method entirely. I'm more inclined to the first approach, so you would just do: app -h switchname --Eric -- "It works better if you plug it in!" --Sattinger's Law
Re: Getopt::Helpful - online help and options
Hi, I haven't tested your code (will do this week-end) and I think it's a
good idea.
I already do what your module proposes to help with but I haven't had the
idea to make a module out of it.
my format looks like this:
my @flags_and_help =
(
'h|help' => \$pbs_config->{DISPLAY_HELP}
'Displays this help.',
''",
'hs|help_switch=s'=> \$pbs_config->{DISPLAY_SWITCH_HELP},
'Displays help for the given switch.',
''" ,
'c|colorize' => \$PBS::Output::colorize,
'Colorize output.',
< pbs -h | grep what_I_am_looking_for
which is very useful to remember some switch (I have well over 150 of those)
and a long help used like this:
$>pbs -hs colorize
lately I have added, to the application, a self search feature that extract
and display information embeded in pod.
I believe it would be good to let the users of you module define what , how
many types and how they want the help. So even my format is limiting.
You could still have some default values and types for the user that is
happy with what comes standard with the module.
Searching within the switch help is very usefull and should be supported.
I'll contribute a patch if you wish.
Cheers, Nadim.
Please CC me at [EMAIL PROTECTED] as I don't have news at home.
Getopt::Helpful - online help and options
I've made some changes to this since we had last discussed it. The
new methods allow you to do without a main::usage() subroutine, and
provide some DWIM functionality. Sorry, it is not on CPAN yet.
Any feedback on the interface/usability would be appreciated. Below
is the synopsis, the code is available at:
http://ericwilhelm.homeip.net/svn/Getopt-Helpful/trunk/code/Getopt/Helpful.pm
=head1 SYNOPSIS
This module provides methods which integrate help messages into a
Getopt::Long option spec. This gathers documentation and declaration
into one place and allows you to utilize perl code to state the
default values of options in your online help messages (helping you
utilize the single-point-of-truth principle.)
Additionally, it provides DWIM methods (Get) which allow you to cut
some standard error-checking code from your scripts. There is even a
handy usage() method which eliminates that silly block of code from
the beginning.
#!/usr/bin/perl
use warnings;
use strict;
use Getopt::Helpful;
my $var1 = "default";
my $req_arg;
# declare this as 'our' or $main::verbose
our $verbose = 0;
# every option must be passed into the constructor...
my $hopt = Getopt::Helpful->new(
usage => 'CALLER [options]',
[
'var=s', \$default,
'',
"setting for \$var1 (default: '$var1')"
],
[
'a|arg, \$req_arg,
'',
'required argument'
],
'+verbose',
'+help',
);
# call GetOptions() behind the scenes (with error-checking)
$hopt->Get();
$req_arg or ($req_arg = shift);
# usage() called with a message results in non-zero exit code
$req_arg or $hopt->usage('missing required argument');
$verbose and warn "doing stuff now\n";
# now do stuff...
=cut
Thanks,
Eric
