From: Massimiliano Mirra - bard <mmirra@...>
Date: 2004-11-04T17:48:45+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
>
> I don't think the code above is proper GetoptLong code.  I don't remember
> exactly but the occurrence of ARGV in the loop makes me suspicious.


>> I'd like to migrate to optparse, though.  But how can I stop argument
>> parsing at a certain point in optparse?
>
> Command line option parsing libs normally do that for you as long as you
> don't have any special requirements.  If you need to stop parsing options
> after a special option #terminate might do what you need.  

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.

> Reconsidering your situation this is what I'd do: iterative parse all
> remaining options starting with the full set at the beginning.  

Bypassing optparse?

> 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).  Then again, if you're thinking that things get
muddy when opt2 has an optional argument, I do agree...

> 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?

Massimiliano