Merge lp:~dave-cheney/gnuflag/001-parse-more-gnu-args into lp:~gophers/gnuflag/trunk
| Status: | Needs review |
|---|---|
| Proposed branch: | lp:~dave-cheney/gnuflag/001-parse-more-gnu-args |
| Merge into: | lp:~gophers/gnuflag/trunk |
| Diff against target: |
66 lines (+12/-4) 2 files modified
flag.go (+6/-2) flag_test.go (+6/-2) |
| To merge this branch: | bzr merge lp:~dave-cheney/gnuflag/001-parse-more-gnu-args |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| The Go Language Gophers | 2012-10-02 | Pending | |
|
Review via email:
|
|||
Description of the Change
add --format=json style gnu args parsing
| Dave Cheney (dave-cheney) wrote : | # |
- 13. By Dave Cheney on 2012-10-02
-
moar test
| Roger Peppe (rogpeppe) wrote : | # |
thanks for working on this - it needed doing!
a few thoughts below.
https:/
File flag.go (right):
https:/
flag.go:729: if len(v) > 1 && len(v[1]) > 0 {
this seems a bit odd to me. i think it's perfectly ok to have an empty
*value*, but an empty flag is wrong.
i think we need to return an error here if there's an empty flag. if we
store the entire string following the flag (including the leading '=')
inside f.procFlag, then parseGnuFlagArg can know that it's got that
style of flag, and process accordingly.
that way we allow the following cases:
--foo=false
-x=true
--bar=
but not
--=x
i think -= should probably be an error too.
https:/
File flag_test.go (right):
https:/
flag_test.go:127: "--format=json",
more test cases here please.
| Roger Peppe (rogpeppe) wrote : | # |
See alternative CL at https:/
On 2 October 2012 12:15, <email address hidden> wrote:
> Thank you for your comments. I have a slight worry about scope creep, we
> only have to support --format=json to fix the current bug in juju.
>
>
>
> https:/
> File flag.go (right):
>
> https:/
> flag.go:729: if len(v) > 1 && len(v[1]) > 0 {
> On 2012/10/02 07:10:01, rog wrote:
>>
>> this seems a bit odd to me. i think it's perfectly ok to have an empty
>
> *value*,
>>
>> but an empty flag is wrong.
>
>
>> i think we need to return an error here if there's an empty flag. if
>
> we store
>>
>> the entire string following the flag (including the leading '=')
>
> inside
>>
>> f.procFlag, then parseGnuFlagArg can know that it's got that style of
>
> flag, and
>>
>> process accordingly.
>
>
>> that way we allow the following cases:
>> --foo=false
>
>
> yup, will fix.
>
>> -x=true
>
>
> I don't think this is valid gnuarg
Hmm, that's a good point. I should disallow = for single-letter flags.
>> --bar=
>
>
>> but not
>> --=x
>
>
> good point, this has no name.
>
>
>> i think -= should probably be an error too.
>
>
> I think it is an error in the same way -x=true is an error
actually, -x=true is not necessarily an error with GNU flag parsing - it
specifies that -x has the argument "=true".
-=true is always an error though, as is -=.
Unmerged revisions
- 13. By Dave Cheney on 2012-10-02
-
moar test
- 12. By Dave Cheney on 2012-10-02
-
support --format=json style gnu args

Please take a look.