From: Robert Klemme <shortcutter@...>
Date: 2010-06-13T00:05:05+09:00
Subject: Re: Option parsers that support single-dash words?

On 11.06.2010 20:06, Jos Backus wrote:
> On Fri, Jun 11, 2010 at 03:25:06PM +0900, Robert Klemme wrote:
>> Drop your requirement.  Think about it: what you require is extremely
>> hard to do.  How do you expect the option parsing to work reliably in
>> light of ambiguity?  If for example -e is also a valid option then what
>> do you make of this?  Since you likely also want to recognize -h you
>> have the ambiguity built in right from the start.
>
> Well, while I agree with you, my colleagues will claim that Perl's
> Getopt::Long pulls it off :)

Several thoughts come to mind.  First of all, even Perl cannot remove 
the ambiguity - their implementation will simply automatically favor one 
interpretation over another.  For me personally Perl is not a role model 
for what we should do in Ruby land.  Perl has it's merits but my 
preference is clearly on a clean object model and clean syntax - even if 
Ruby is slower in some benchmarks.

Btw, could be that even POSIX mandates double dashes for long options.

Guideline 5:
     Options without option-arguments should be accepted when grouped 
behind one '-' delimiter.

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html

This _can_ be read as exclusion of a single word option behind a single 
dash.  But then again POSIX does not say anything about long option names.

>> Alternatively, you could preprocess the arguments and look for "-help"
>> yourself e.g.
>>
>> ARGV.map! {|arg| '-help' == arg ? '--help' : arg}
>
> Yeah, but you'd have to do that for all the long option words.
>
> I wonder, is there an easy way to get the list of long option names from
> optparse? If there was, you could do the above replacement only on those
> elements of ARGV that are a long option, and keep bundled arguments such as
> `-Dfoo=bar' working as it wouldn't match any of the long option names.
>
> Any ideas?

Yes, you can use #instance_variable_get to access internal structures of 
OptionParser.  If you want to find out about internals you can either 
try documentation or investigate with IRB, e.g. http://pastie.org/1001813

You might be able to get the long option via  x.long.keys where x is an 
instance of OptionParser::List or analyzing OptionParser::Switch and 
reading #long (see the output in pastie for navigation).

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/