Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Option parsers that support single-dash words?

Reply
Thread Tools

Option parsers that support single-dash words?

 
 
Jos Backus
Guest
Posts: n/a
 
      06-11-2010
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

 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      06-11-2010
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/
 
Reply With Quote
 
 
 
 
Jos Backus
Guest
Posts: n/a
 
      06-11-2010
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

 
Reply With Quote
 
Walton Hoops
Guest
Posts: n/a
 
      06-11-2010
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.


 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      06-12-2010
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/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
page.aspx?option - how to detect "option" Kevin Blount ASP .Net 6 11-28-2006 09:21 PM
DHCP relay agent versus Option 3; Routers Option lcorrigan Cisco 2 09-27-2006 05:18 PM
no 'option' in aspx file means 'option'="false"? Cas ASP .Net 5 08-28-2006 10:36 AM
g++ -pg option and -shared option Julien ROUZIERES C++ 1 12-21-2004 02:30 PM



Advertisments