Optparse bug?

ruby-talk
1

Is this a bug?

$ cat bug.rb
require 'optparse'

OptionParser.new do |prsr|
   prsr.on("-a",
           "please use the",
           "-b option instead")
# ^
# insert a space above the caret to prevent
# detection of -b as an option.

···

#

   prsr.on("-b", "--foo-bar")

   prsr.parse!(ARGV)
end

__END__

$ ruby bug.rb -h
Usage: bug [options]
     -a, -b option instead please use the
         --foo-bar

2

Hi,

At Sat, 25 Jun 2005 14:15:43 +0900,
Joel VanderWerf wrote in [ruby-talk:146437]:

OptionParser.new do |prsr|
   prsr.on("-a",
           "please use the",
           "-b option instead")
# ^
# insert a space above the caret to prevent
# detection of -b as an option.
#

OptionParser treats a string starts with "-" as an option name.

···

--
Nobu Nakada

3

Is that the right behavior though? Maybe after the first non-option string (in this case "please use the"), the parser should assume that the rest of the strings are also not options.

It's really easy to run into this situation if you reference another option in the descriptive text, and then re-wrap the text.

···

nobu.nokada@softhome.net wrote:

Hi,

At Sat, 25 Jun 2005 14:15:43 +0900,
Joel VanderWerf wrote in [ruby-talk:146437]:

OptionParser.new do |prsr|
  prsr.on("-a",
          "please use the",
          "-b option instead")
# ^
# insert a space above the caret to prevent
# detection of -b as an option.
#

OptionParser treats a string starts with "-" as an option name.

4

Isn't the POSIX behavior to use "--" as a option/non-option barrier?

I.e.:

ls -l # lists all files in long format
ls -- -l # list a file named "-l"

···

On 6/25/05, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

nobu.nokada@softhome.net wrote:
> Hi,
>
> At Sat, 25 Jun 2005 14:15:43 +0900,
> Joel VanderWerf wrote in [ruby-talk:146437]:
>
>>OptionParser.new do |prsr|
>> prsr.on("-a",
>> "please use the",
>> "-b option instead")
>># ^
>># insert a space above the caret to prevent
>># detection of -b as an option.
>>#
>
>
> OptionParser treats a string starts with "-" as an option name.
>

Is that the right behavior though? Maybe after the first non-option
string (in this case "please use the"), the parser should assume that
the rest of the strings are also not options.

5

Michael Campbell wrote:

Hi,

At Sat, 25 Jun 2005 14:15:43 +0900,
Joel VanderWerf wrote in [ruby-talk:146437]:

OptionParser.new do |prsr|
prsr.on("-a",
         "please use the",
         "-b option instead")
# ^
# insert a space above the caret to prevent
# detection of -b as an option.
#

OptionParser treats a string starts with "-" as an option name.

Is that the right behavior though? Maybe after the first non-option
string (in this case "please use the"), the parser should assume that
the rest of the strings are also not options.

Isn't the POSIX behavior to use "--" as a option/non-option barrier?

I.e.:

ls -l # lists all files in long format
ls -- -l # list a file named "-l"

On the command line, yes. But I'm asking about arguments to the OptionParser#on method. Are you suggesting to use "--" as a barrier string in that context too?

It seems to me the best solution is to assume that once #on has encountered a non-option (i.e., descriptive text) in its list of arguments then all subsequent arguments should be treated as descriptive text. That would ensure that, if your text refers to option names, then reformatting your text will not cause them to be treated as options. Would any useful behavior be lost that way?

···

On 6/25/05, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

nobu.nokada@softhome.net wrote:

6

>>Is that the right behavior though? Maybe after the first non-option
>>string (in this case "please use the"), the parser should assume that
>>the rest of the strings are also not options.
>
> Isn't the POSIX behavior to use "--" as a option/non-option barrier?
>
> I.e.:
>
> ls -l # lists all files in long format
> ls -- -l # list a file named "-l"

On the command line, yes. But I'm asking about arguments to the
OptionParser#on method. Are you suggesting to use "--" as a barrier
string in that context too?

Not necessarily asking for (nor NOT asking for) that behavior, but I
do think that it would be an easy metaphor to consider carrying
forward. Consistency and all that... (yeah yeah, I know the Emerson
quote. <g>)

It seems to me the best solution is to assume that once #on has
encountered a non-option (i.e., descriptive text) in its list of
arguments then all subsequent arguments should be treated as descriptive
text. That would ensure that, if your text refers to option names, then
reformatting your text will not cause them to be treated as options.
Would any useful behavior be lost that way?

Probably not. I can't say that I've seen (m)any command line tools
that would behave differently (although the "gem" command seems oddly
backwards to me in this...)

···

On 6/25/05, Joel VanderWerf <vjoel@path.berkeley.edu> wrote: