Specify how flags are parsed

[duglin]

See https://github.com/docker/docker/issues/7396 - I think we need avoid the situation that Docker has right now by saying that we're going to do what getopts does.

ping @mikebrow

[mikebrow]

dibs

[wking]

On Wed, Dec 09, 2015 at 05:52:49AM -0800, Doug Davis wrote:

See https://github.com/docker/docker/issues/7396

Heh, -ff gobbling too futher arguments is not fun :p.

I think we need avoid the situation that Docker has right now by saying that we're going to do what getopts does.

I agree that we want runtimes to be a bit better behaved (and if I were writing a runtime, I'd use getopt_long 1 or some other suitably robust option parser). But I don't know that we need to specify it in this minimal command-line API. All of the requirements here use long options (with the GNU-style ‘--’ prefix for compatibility with getopt_long, but you could use another parser if you want too, notes in 9d97d395). If runtimes want to provide short options as well, I'm all for that, but we don't need to specify them here (we can build higher-level tooling like test suites that just use the required long options).

[duglin]

My use of the term "getopts" wasn't meant to limit us to just single dash options, I just meant I wanted something well defined and "normal" :-)

I do actually think we should mandate how options are parsed because if we don't then we'll get inconsistencies and confusion. If we just tried to specify it for just the options we define but then allow some other (weird) parsing scheme for app-specific options then I think we're hurting the UX and our customers. IMO they would want consistency. As long as we don't manadate something bizarre I don't think this will be an issue anyway.

I also think we'll have single-dash options at some point as part of the spec.

[wking]

On Wed, Dec 09, 2015 at 09:43:33AM -0800, Doug Davis wrote:

I do actually think we should mandate how options are parsed because if we don't then we'll get inconsistencies and confusion.

Folks that want portable (between runtime) options should stick to the stuff defined in this repository, and we'll test all of that to ensure consistency. If runtimes want to differentiate themselves by using different short options or parsing schemes for extensions, that's between them and their users. I'd certainly recommend they pick something sane, but I don't see a need to require it before certifying runtime conformance.

I also think we'll have single-dash options at some point as part of the spec.

What can you do with single-dash options that you can't do with long options? Again, we're just looking for the minimum API required for conformance testing, after which we can leave runtimes to do their own thing.