Option parsers that support single-dash words?

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?

On 11.06.2010 07:40, Jos B. 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

On Fri, Jun 11, 2010 at 03:25:06PM +0900, Robert K. 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 :slight_smile:

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!

On 6/11/2010 12:06 PM, Jos B. wrote:

Getopt::Long pulls it off :slight_smile:
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 B. wrote:

On Fri, Jun 11, 2010 at 03:25:06PM +0900, Robert K. 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 :slight_smile:

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.

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