You can pass code references to GetOptions, such as

perl -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
[download]

which gives

$VAR1 = [
          {
            'forever' => 1,
            'channel' => '1'
          },
          {
            'hours' => 20,
            'minutes' => 10,
            'channel' => '2'
          },
          {
            'forever' => 1,
            'channel' => '3'
          }
        ];
[download]

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.