Option parsers that support single-dash words?

Discussion in 'Ruby' started by Jos Backus, Jun 11, 2010.

  1. Jos Backus

    Jos Backus Guest

    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
     
    Jos Backus, Jun 11, 2010
    #1
    1. Advertising

  2. 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/
     
    Robert Klemme, Jun 11, 2010
    #2
    1. Advertising

  3. Jos Backus

    Jos Backus Guest

    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
     
    Jos Backus, Jun 11, 2010
    #3
  4. Jos Backus

    Walton Hoops Guest

    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.
     
    Walton Hoops, Jun 11, 2010
    #4
  5. 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/
     
    Robert Klemme, Jun 12, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    446
    Jukka K. Korpela
    Dec 10, 2005
  2. Fredrik Lundh
    Replies:
    0
    Views:
    660
    Fredrik Lundh
    Nov 20, 2005
  3. Fredrik Lundh
    Replies:
    0
    Views:
    510
    Fredrik Lundh
    Nov 21, 2005
  4. Rigour
    Replies:
    4
    Views:
    1,457
    Neredbojias
    Nov 17, 2009
  5. Replies:
    10
    Views:
    308
Loading...

Share This Page