«

Hi,

In order to convert some legacy Perl code that uses Getopt::Long, I'm looking
for an option parser that supports `-help' in addition to `--help'. All the
option parser libraries I have looked at only support the latter, and always
do bundling, turning `-help' into `-h -e -l -p' which is not what I want.

Any suggestions, please?

--
Jos Backus
jos at catnook.com

On 11.06.2010 07:40, Jos Backus wrote:

> In order to convert some legacy Perl code that uses Getopt::Long, I'm looking
> for an option parser that supports `-help' in addition to `--help'. All the
> option parser libraries I have looked at only support the latter, and always
> do bundling, turning `-help' into `-h -e -l -p' which is not what I want.
>
> Any suggestions, please?

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.

Alternatively, you could preprocess the arguments and look for "-help"
yourself e.g.

ARGV.map! {|arg| '-help' == arg ? '--help' : arg}

Kind regards

robert

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

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

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

Thanks, Robert!

--
Jos Backus
jos at catnook.com

On 6/11/2010 12:06 PM, 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
>
>
>> 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?
>
> Thanks, Robert!
>
>
Maybe the getopt gem? Both are wrappers around the same C Library, so I
would expect them to have the same functionality.

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/...bd_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/