optparse bug?

[Joel VanderWerf]

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

 

[nobu.nokada]

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.

 

[Joel VanderWerf]

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.

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

 

[Michael Campbell]

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.

=20
=20
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"

 

[Joel VanderWerf]

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?

 

[Michael Campbell]

=20
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

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...)