From: Massimiliano Mirra - bard <mmirra@...>
Date: 2004-11-07T23:48:38+09:00
Subject: Re: From getoptlong to optparse

"Robert Klemme" <bob.news@gmx.net> writes:

>> >>     while ARGV.first =~ /^-/
>> >>       opt, arg = opts.get
>> >>       case opt
>> >>       when "--host"
>> >>         config["host"] = arg
>> >>       when "--port"
>> >>         config["port"] = arg.to_i
>> >>       end
>> >>     end

>> Not exactly.  I need to stop parsing when a special command is seen.
>> "--host" and "--port" in the above example might appear in a different
>> order or not appear at all, so they're not reliable.
>
> Do you mean the problem is that you need to stop when a command is seen
> *and* this command can occur anywhere, i.e. also behind an option with an
> optional argument?

Yes and no.  Yes: this command can occur anywhere after one or more
options.  No: I have no options with optional arguments so far, so I
haven't dealt with this case which I suspect to be more complex.

>> > Evaluate the first non option, this is your next command.
>>
>> This needs to go hand in hand with option parsing.  Consider this:
>>
>>   $ prog --opt1 arg1 --opt2 stuff --blah
>>
>> Is `stuff' a subcommand or opt2's argument? That depends on opt2's
>> definition (which in GetoptLong means NO_ARGUMENT or
>> REQUIRED_ARGUMENT).
>
> You have the same (or finer) level of control for option arguments in
> optparse, too.

The kind of control I am trying to get was not given by GetoptLong per
se, but by the `while ARGV.first =~ /^-/', which breaks down parsing
in chunks where the subcommand can be detected.

>>  Then again, if you're thinking that things get
>> muddy when opt2 has an optional argument, I do agree...
>
> Yes, they certainly get muddy at this point.  They get as muddy as to be
> undecidable if you have a command that is also a valid optional argument
> of an option.  You can't decide what it is other than defining a priority
> for the resolution of this ambiguity.

Yes.  Or just disallowing optional arguments for generic options, the
need hasn't arisen so far and I doubt it will at least for this application.

>> > Eat it and go to the first step only now remembering that options
>> > are stored for this command.  Repeat until there are no more args
>> > left or the first non option is not a command (i.e. file name,
>> > ignorable or whatever).
>>
>> How is this different from the ARGV loop above?
>
> You have two nested loops, one of them is hidden in optparse.

Sorry but I still can't make a picture of what you are suggesting.
Would you mind sketching a couple of lines of pseudocode?

Massimiliano