# The following was supposedly scribed by # Eric Wilhelm # on Thursday 01 July 2004 02:07 am:
>Well, the help_string() function is operable now and into the subversion > repo at http://ericwilhelm.homeip.net/svn/Getopt-Helpful/trunk/code/Getopt/ A slight fix for my silly typo and some new functionality here now. Also, I've corrected the documentation to refer to the correct module:) Charging headlong into the dangers of DWIM, I've added some builtin options which become available by using a string instead of an array reference in your spec. use Getopt::Long; use Getopt::Helpful; my $hopt = Getopt::Helpful->new( ['choice=s', \$choice, '<choice>', 'your choice (default $choice)'], '+help', '+verbose', '+debug', ); GetOptions($hopt->opts); ############# I think I'll give up on creating dynamic pods for now. The best scenario that I've thought of so far is to leave a hole in the pod text which would get filled in by the results of `$0 --help` and then saving that into "$0.pod". Possibly, this would be activated with $0 --makepod, so that I could at least have a cron job keep my docs updated with a simple 'for i in bin_dir/*;do $i --makepod;done Anyway, the real reason to have the pods be dynamic was to show the default values for the options. So, I've decided to populate the pod with a more verbose discussion of each option, with an aside that the defaults can be seen when you ask for --help. Long-term, I think the pod-parsing option specs are maybe the better way to go. The trouble is mostly that you lose the power of Perl when you write everything out in the pod. So, some combination of Getopt::Declare with Pod::Constants might get us there (provided that perldoc will then cooperate.) =nspod =head1 To be continued... =cut --Eric
