# The following was supposedly scribed by # imacat # on Friday 17 June 2005 02:51 am:
> I did not notice the go_shop problem. But I think it's trivial to >solve that with Getopt::Long: > >my @conf_fishes = read_conf("fish"); # get qw(trout) >my @opt_fishes = qw(); >my $opt_nofish = 0; >Getopt::Long::GetOptions( > "fish=s" => [EMAIL PROTECTED], > "no-fish" => \$opt_nofish, >); >@conf_fishes = qw() if $opt_nofish; >my @fishes = (@conf_fishes, @opt_fishes); Yes. You can solve it. It's not really trivial by the time you add meats, cheeses, breads, and mustard though. All of these things come in many "flavors" and you might have a config file with your favorites listed in it so that running "go_shop" with no arguments gives you a routine trip, but you want to be able to change these things when you get bored of the same-old options. These 4 extra lines multiply by 5 items so far. > Who said the variable to save the "no-fish" status has to be >revelant with the "fish" variable anyway? If they are saved in >different variables, the order doesn't matter, does it? What I'm trying to do with Getopt::Modern here is to establish some conventions which allow this to happen internally. This saves the author some code and gives the user a guaranteed consistent experience with multiple programs. The debate on the usefullness of '--no-' appears to say it's useful. The debate on its behavior says that there are historical (and convenience) reasons to keep its evaluation in command-line order. What I'll probably end-up with is something like '--un-' performing the above task of initializing internal values. --Eric -- "Everything goes wrong all at once." --Quantized Revision of Murphy's Law --------------------------------------------- http://scratchcomputing.com ---------------------------------------------