-
Notifications
You must be signed in to change notification settings - Fork 60
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
Questions about parsing of long flags with = in them #138
Comments
Interesting edge cases! Let me consider your use cases from first principles...
So, all of I'm not currently sure if this behavior is intentional, or accidental, in terms of the implementation. I hope it's not an accident.
Definitely surprising! My intuition is that If Thank you for the issue. |
Full disclosure: I am writing my own flag-parsing library (because clearly Go needs another one), and I came across these questions while h̶e̶a̶v̶i̶l̶y̶ b̶o̶r̶r̶o̶w̶i̶n̶g̶ consulting
I will push back on this briefly, but then stop bugging you about it. When you say "etc.", that feels a little handwavey to me. Some additional details: if there is a value captured on the right-hand side of tl;dr - the way you currently handle boolean flags is inconsistent; sometimes you follow the (documented) logic of
I will work on a PR this weekend.
Again, thank you for |
You make fair points. Let's consider a few separate cases.
In this case I think it's clear that we set debug to true, no ambiguity.
Here we have an equal sign but no subsequent value, and no further characters beyond the equal sign that could possibly be interpreted as a value. From my perspective, every flag passed at the command line is always a 2-tuple of flag name and assigned value. Passing I understand the perspective that
Here we clearly see that the debug flag is set to the empty string, which would evaluate to false. All good, I hope.
I think this claim relies on the assumption that |
I was assuming that When I work on the other issue, I'll see if it makes sense to add anything to the docs. If it does, I'll make a separate PR for that. Thanks. |
(First, thanks for ff.) I'm using v4, and I have some questions about how ff.FlagSets parse long flags that use
=
. After looking at the code, I'm not sure whether I'm seeing a bug or just a feature that I didn't expect.--flagname=
(that is, with a long flag and no value after=
) are parsed as true. Based on this comment, you may be doing this deliberately, but I'm inclined to think that this is a bug resulting from how you handle=
earlier inparseLongFlag
.=
consume the nextarg
as their value. This can have very surprising results for users who mistakenly forget a value after=
. Consider the following.By way of comparison, stdlib's
flag
treats all empty values after=
as errors except for string flags. (Presumably because they only return an error if astrconv
conversion fails, and there is no conversion in the case of string values. An empty value ==""
.) This strikes me as the right approach (maybe even string flags should fail here). Leaving out a value is presumably user error, and parsing should fail and stop. (Alternatively, the treatment of empty values with=
should be documented.)If this is a bug, I think I have a fix, and I'm happy to make a PR. Let me know what you think.
The text was updated successfully, but these errors were encountered: