Bug #7537
closedOptionParser treats negative digits as options
Description
Is it intentional that negative digits are treated as options?
If I use negative digit as an argument of an option, it is treated as a number
OptionParser.new {|opts|
opts.on('-p','--pvalue VAL', Integer, 'P-value') {|v| puts "P-value: #{v}" }
}.parse!
ruby my_test.rb -p -1
works normally
But if I use it as optional argument of an option:
OptionParser.new {|opts|
opts.on('-p','--pvalue [VAL]', Integer, 'P-value') {|v| puts "P-value: #{v}" }
}.parse!
ruby my_test.rb -p -1
fails with "Invalid option -1"
Also I can't use it as non-optional argument
OptionParser.new {|opts|
opts.on('-n', 'no Pvalue argument, other arguments only') {}
}.parse!
puts ARGV
ruby my_test.rb -1
also fails with "Invalid option -1"
Files
Updated by prijutme4ty (Ilya Vorontsov) almost 12 years ago
In my opinion, negative numbers shouldn't be treated as option keys unless it was explicitly specified. In other cases them should be treated as usual parameters.
Updated by zzak (zzak _) almost 12 years ago
- Category set to lib
- Assignee set to nobu (Nobuyoshi Nakada)
Updated by usa (Usaku NAKAMURA) almost 12 years ago
- Status changed from Open to Assigned
Updated by prijutme4ty (Ilya Vorontsov) over 11 years ago
Sent a pull-request. https://github.com/ruby/ruby/pull/259
I've made changes the same way as python do -- http://docs.python.org/dev/library/argparse.html#arguments-containing
This patch introduces one possible (but not very serious and very rare) incompatibility: if one already uses explicitly defined negative-digit option such as '-1' and also uses an option with optional argument '-p [ARG]' and runs a command with options '-p -1' then before patch it'll be treated as two different options '-p', '-1' and after patch they are treated as an option '-p' with value '-1'.
If one meets this problem, he can use option declaration with equal sign: '-p=[ARG]' or just change places of arguments and run his program with options '-1 -p'.
But I suppose not too many people use explicitly defined numeric options and even less people use optional argument with them in such order (may be even nobody use it such a way).
Also, if possible, backporting into 1.9 of this patch will be very useful. Unfortunately I don't know how should I do this.
Updated by zzak (zzak _) over 11 years ago
I've attached the patch from the associated pull request.
Updated by prijutme4ty (Ilya Vorontsov) about 11 years ago
Any thoughts about this patch?
Updated by jeremyevans0 (Jeremy Evans) about 5 years ago
- Status changed from Assigned to Closed
I don't think this is a bug, I think this is expected behavior. When parsing -p -1
, where -p
accepts an optional argument, OptionParser correctly treats the -1
as a new option, and raises an error as the parser does not accept that option. You have to specify the optional argument a different way to tell OptionParser that the -1
is the value for the optional argument. One way is -p-1
, another is --pvalue=-1
.