[#8815] Segfault in libc strlen, via rb_str_new2 — "Sean E. Russell" <ser@...>

Howdy,

12 messages 2006/09/09
[#8817] Re: Segfault in libc strlen, via rb_str_new2 — Eric Hodel <drbrain@...7.net> 2006/09/09

On Sep 8, 2006, at 10:10 PM, Sean E. Russell wrote:

Re: [PATCH] OptionParser < Hash

From: "Nobuyoshi Nakada" <nobu@...>
Date: 2006-09-11 01:18:36 UTC
List: ruby-core #8831
Hi,

At Mon, 11 Sep 2006 00:14:57 +0900,
greg weber wrote in [ruby-core:08826]:
> This is a 5 line patch will allow for the use of OptionParser itself
> to automatically store values from options.  Now options can be built
> in the following manner:

Thank you, but sorry, it's not acceptable.  The idea that OptionParser
holds values in itself was that I used in the very first days and have
thrown it away after all.

OptionParser's methods are partioned to 2 kinds.  Methods to register
the options, and methods to parse the command line.  The former does
modify the receiver, but the latter never.  I don't plan to change
this concept.

> By default, there will be a hash key for the long form of the option
> and its value will be the return of the block.  If necessary, this can
> be avoided by returning nil.

Seems that returning nil just stores nil

> I was also wondering if there is any way to specify mutually exclusive
> or required options with optparse.

Maybe,

  @text = true
  @eol = nil
  OptionParser.new do |q|
    ot = q.def_option("--text") {@text = true}
    ob = q.def_option("--binary") {@text = false}
    oe = q.def_option("--eol=EOL", %w[UNIX DOS OS9]) {|eol| @eol = eol}
    q.exclusive(ob, oe)		 # <=== eol and binary are exclusive
    q.requires(oe, ot)		 # <=== eol requires text
  end

-- 
Nobu Nakada

In This Thread