[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

optparse bug?

Joel VanderWerf

6/25/2005 5:16:00 AM


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
5 Answers

nobu.nokada

6/25/2005 6:27:00 AM

0

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

Joel VanderWerf

6/25/2005 7:04:00 AM

0

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.

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

6/25/2005 1:40:00 PM

0

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.


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

6/25/2005 7:29:00 PM

0

Michael Campbell wrote:
> 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.
>
>
>
> 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

6/25/2005 9:06:00 PM

0

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

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