in reply to GetOpt::Long usage style

This kind of redundancy has never really bothered me. I usually use Getopt::Long in conjunction with Pod::Usage and my 'skeleton' usually looks like:
use Getopt::Long; use Pod::Usage; our ($user,$pass,$numb,$help); GetOptions( 'user|u=s' => \$user, 'pass|p=s' => \$pass, 'numb|n=i' => \$numb, 'help|h|?' => \$help, ); $numb ||= 42; pod2usage(-verbose=>2) if $help; pod2usage(-verbose=>1) unless $user and $pass; __END__
Considering that the variables used to hold user options are being shared across two (or more) packages, this doesn't seem overly redundant to me. But that's just me. ;)

UPDATE: hmmm, here is something evil:

our ($user,$pass,$numb,$help); my @tmpl = ( 'user|u=s', 'pass|p=s', 'numb|n=i', 'help|h|?', ); @tmpl = map {"'$_' => \\\$@{[(split('\|',$_))[0]]},"} @tmpl; eval "GetOptions(@tmpl);";


(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re^2: GetOpt::Long usage style
by Aristotle (Chancellor) on Mar 09, 2003 at 01:16 UTC
    No eval, complies with strict:
    our ($user,$pass,$numb,$help); my @cmdopt = ( [qw(user u=s)], [qw(pass p=s)], [qw(numb n=i)], [qw(help h ?)], ); GetOptions(map { +(join '|', @$_) => *{$main::{$_->[0]}}{SCALAR} } @cm +dopt);
    It will even bomb out if your variable and option names mismatch:
    Use of uninitialized value in ref-to-glob cast at line ##.
    Can't use string ("") as a symbol ref while "strict refs" in use at line ##.
    Of course, this assumes that the variables live in package main. If you need them elsewhere, the $main:: bit will need adjustment. It is possible to generalize even that bit, but that requires some painful twisting - or disabling the ref stricture.

    Makeshifts last the longest.