felixSchl/neodoc

Mutually exclusive positional arguments and long/short options..

steve-a-jones opened this issue · 5 comments

A bit new to command line parsing, but after trying numerous libraries neodoc is without doubt the superior choice - nice work!

Question:
I am trying to set up a command so that I can receive positional arguments OR options (long/short). This way the user can have flexibility when building their command query.

I seem to have been able to achieve this with the following -

fbit configure ([<client-id> <client-secret>]|[--clientid=<client-id> --clientsecret=<client-secret>])

(Great)
$ fbit configure 123 456
{ '<client-id>': 123, '<client-secret>': 456, configure: true }

(Great)
$ fbit configure --clientid 123 --clientsecret 456
{ '--clientid': 123, '--clientsecret': 456, configure: true }

I am a bit confused by the error thrown in this case though -

$ fbit configure --clientid 123
fbit: unexpected option --clientid

How can I correct my syntax so that this error will more closely reflect the truth? I was more expecting fbit: option requires argument: --clientsecret.

Appreciate the help!

I think what you would expect would be missing required option --clientsecret.

This roughly equivalent usage doc would give you that:

usage: fbit configure [<client-id> <client-secret>
                      |--clientid=<client-id> --clientsecret=<client-secret>
                      ]

Now:

$ configure --clientid 123
fbit: missing --clientsecret=<client-secret>
$ configure --clientid 123 --foo
fbit: unknown option --foo. Expected --clientsecret=<client-secret>
$ fib configure --clientid 123 --clientsecret
fbit: option requires argument: --clientsecret

EDIT: Break usage syntax across lines. Try to keep you help texts at 72/80 chars max.

Perfect, thanks for the quick reply!

I ended up with this since I needed them required -

usage: fbit configure (<client-id> <client-secret>
                      |--clientid=<client-id> --clientsecret=<client-secret>
                      )

I am happy it works for you :) I assume this means we can close this.

@steve-a-jones Just a heads up, I am currently releasing the first release candidate for the 1.x series of neodoc which coincidentally would've given you the same error message for both ways of writing the spec. If you're keen to try it out and report any issues with it, you can do so via npm install neodoc@1.0.0-rc.0 once it's on npm :)

@felixSchl Thanks! I'll give this a try soon and report any issues if found.