-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option values starting with dashes don't work #118
Comments
Does the following work for you?
|
Yes, it works, and yes, I can use that as a workaround, thanks. I still consider this to be a bug, though. If the CLI argument in position N is an option requiring a value and doesn't contain a For me the situation seems slightly different when the option has a default. Let's take this small modification of my original program (only adding a default to
Let's run this: [0 mosu@sweet-chili ~/test] ./ruby1.rb --action --ignore
{:action=>"default_action",
:ignore=>true,
:help=>false,
:action_given=>true,
:ignore_given=>true} I can see how that is ambiguous and no fun situation to be in. I haven't done an extensive study of existing command line parsers out there, and I'm well aware that there's no standard for this. Just a couple of examples:
|
Yeah, I can see both sides to the issue due to the ambiguities. I think it would be most helpful to see how other option parsers handle things like this. I think it also gets tricky with the "strings" type, where we wouldn't know where the next option would start. I'm not sure how we could resolve that in a consistent way with other options. |
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:
Here are a couple of examples:
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 theaction
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.
The text was updated successfully, but these errors were encountered: