# Option parsers that support single-dash words? **URL:** \ **Category:** Ruby\ **Created:** [June 11, 2010, 7:40am UTC](https://www.ruby-forum.com/t/option-parsers-that-support-single-dash-words/189999 "2010-06-11T07:40:53Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Jos\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/779978/32.png) [@Jos\_B](https://www.ruby-forum.com/u/Jos_B)\ **Post date:** [June 11, 2010, 7:40am UTC](https://www.ruby-forum.com/t/option-parsers-that-support-single-dash-words/189999/1 "2010-06-11T07:40:53Z")
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? ---
**Author:** ![Jos\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/779978/32.png) [@Jos\_B](https://www.ruby-forum.com/u/Jos_B)\ **Post date:** [June 11, 2010, 8:25am UTC](https://www.ruby-forum.com/t/option-parsers-that-support-single-dash-words/189999/2 "2010-06-11T08:25:22Z")
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 ---
**Author:** ![Jos\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/779978/32.png) [@Jos\_B](https://www.ruby-forum.com/u/Jos_B)\ **Post date:** [June 11, 2010, 8:12pm UTC](https://www.ruby-forum.com/t/option-parsers-that-support-single-dash-words/189999/3 "2010-06-11T20:12:04Z")
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 🙂 > 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! ---
**Author:** ![Jos\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/779978/32.png) [@Jos\_B](https://www.ruby-forum.com/u/Jos_B)\ **Post date:** [June 11, 2010, 9:20pm UTC](https://www.ruby-forum.com/t/option-parsers-that-support-single-dash-words/189999/4 "2010-06-11T21:20:00Z")
On 6/11/2010 12:06 PM, Jos B. wrote: > Getopt::Long pulls it off 🙂 > 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. ---
**Author:** ![Jos\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/779978/32.png) [@Jos\_B](https://www.ruby-forum.com/u/Jos_B)\ **Post date:** [June 17, 2010, 4:22pm UTC](https://www.ruby-forum.com/t/option-parsers-that-support-single-dash-words/189999/5 "2010-06-17T16:22:13Z")
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 🙂 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](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](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