I was hoping to be able to require the dependent options within the getopt module
This is how I handle option dependecies. Whether it's clearer than your method is largely a matter of taste. You keep a dependecy near the code that mandates it. I group all of them near the GetOptions call.
use Getopt::Long; use Pod::Usage; my %opt; GetOptions( \%opt, 'help', 'man', 'V|version', 't|timeout=i', 'H|hostname=s', 'p|port=i', 'U|uri=s', ) or pod2usage(2); # standard opt handling; $opt{h} && pod2usage(1); $opt{man} && pod2usage( -exitstatus => 0, -verbose => 2 ); $opt{V} && version(); # option dependencies ( defined($opt{U}) xor defined($opt{H}) ) || pod2usage(1); defined($opt{H}) && defined($opt{p}) || pod2usage(1); # ... go on your merry way knowing dependencies are satisfied __END__ =head1 NAME opttest - Check out Getopt::Long and Pod::Usage =head1 SYNOPSIS opttest [options] -U uri - or - opttest [options] -H <hostname> -p <port> Options: U | -uri uri to check H | -hostname hostname to check p | -port tcp port to check (required with hostname!) ... =head1 DESCRIPTION Optest provides some basic option handling and demonstrates how to handle option dependencies for most-likely cases. =cut
Adding some feedback to the user also helps the code self-document, but does create some clutter:
( defined($opt{U}) xor defined($opt{H}) ) || do { print "Only one of 'hostname' or 'uri' must be specified\n"; pod2usage(1); }; defined($opt{H}) && defined($opt{p}) || do { print "Hostname option requires port option\n"; pod2usage(1); };
--Solo
--
You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.
In reply to Re^3: Getopt::Long subroutine usage
by Solo
in thread Getopt::Long subroutine usage
by rockneybot
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |