You can pass code references to GetOptions, such as
which givesperl -we 'use Getopt::Long; my @channels; GetOptions("channel=s", sub +{ push @channels, {"channel", $_[1]}; }, "forever", sub { $channels[- +1]{"forever"} = 1; }, "minutes=n", sub { $channels[-1]{"minutes"} = $ +_[1]; }, "hours=n", sub { $channels[-1]{"hours"} = $_[1]; }, ); use D +ata::Dumper; print Dumper [@channels];' -- -channel 1 -forever -chann +el 2 -minutes 10 -hours 20 -channel 3 -forever
$VAR1 = [ { 'forever' => 1, 'channel' => '1' }, { 'hours' => 20, 'minutes' => 10, 'channel' => '2' }, { 'forever' => 1, 'channel' => '3' } ];
Of course, you may want a different data structure, use whatever is convenient for the rest of your code.
Update: POSIX getopt (and its extension, GNU's getopt_long) has the correct interface: the right way to get options is to call code provided by the developper. The way perl's Getopt and Getopt::Long tries to be smart and store the data in structures automatically is wrong. It sometimes works, but more often it doesn't, just like this example shows it. It's not too difficult for the developper to write simple callbacks sub { $fooswitch = 1 } instead of a reference \$fooswitch, and it offers much more flexibility.
In reply to Re: GetOptions problem
by ambrus
in thread GetOptions problem
by bory
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |