Why stunt the capabilities of getopt by shoehorning in other kinds of information in its switch strings?
In such cases, I usually just make a more complex structure which associates getopt switches to arrays which contain variables, help texts, validator functions and whatever else. Then I just map out the elements that Getopt::Long expects. For --help, I can also look at the switch strings and other clues to automate some of the messages for consistency.
This code is a sketch from memory. There are other structures that would do just as well.
my $Verbose; my $Secret; %Options = { 'verbose+' => [ \$Verbose, "Makes the output more verbose." ], 'secret!' => [ \$Secret, "Enables secret features." ], }; ... sub usage { ... foreach my $option (sort keys %Options) { my $switch = $option; $switch =~ s/=.*$//; $switch =~ s/\W*$//; $message = $Options{$option}[1]; $message .= " Adding $switch increases the effect." if $option =~ /\+$/; $message .= " Use --no$switch to disable." if $option =~ /\!$/; print Wrap(undef, undef, "$switch: $message"), $/; } ... GetOptions(map { $_, $Options{$_}[0] } keys %Options);
(One should mention the POD::Usage here, but I find it a little stiff, personally.)
--
[ e d @ h a l l e y . c c ]
In reply to Re: "self documenting" switch options
by halley
in thread "self documenting" switch options
by bobn
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |