Description
I have a program taking options with values. Sometimes those values start with a dash. If that happens, optimist
tries to parse those as actual options instead of values, leading either to wrong options being activated or interested error messages.
The expected behavior is that the value after an option requiring a value is always assigned to the that option.
Here's an example:
#!/usr/bin/env ruby
require "optimist"
require "pp"
o = Optimist::options do
opt :action, "an action", :type => :string
opt :ignore, "ignore stuff"
end
pp o
Here are a couple of examples:
[0 mosu@sweet-chili ~/test] ./ruby1.rb --action jump
{:action=>"jump", :ignore=>false, :help=>false, :action_given=>true}
[0 mosu@sweet-chili ~/test] ./ruby1.rb --action --jump
Error: unknown argument '--jump'.
Try --help for help.
[255 mosu@sweet-chili ~/test] ./ruby1.rb --action -a --ignore
Error: option '-a' specified multiple times.
Try --help for help.
[255 mosu@sweet-chili ~/test] ./ruby1.rb --action --ignore
Error: option '--action' needs a parameter.
Try --help for help.
The first case is obviously OK.
The other cases are all really bad. In each case the value after --action
(--jump
in case 2, -a
in case 3 and --ignore
in case 4) should be assigned to the action
option as the spec says that it must have a value.
Background: this is from a script doing DNS validation for the ACME protocol (Let's Encrypt certificates). It has to deal with the auth tokens that the Let's Encrypt servers generate. Today such an auth token started with a dash, and my program broke. I do not have any control over the auth tokens, which characters they consist of etc. A workaround such as "use different argument formats, then" doesn't help if I don't have control over the data my callers must use.
Activity