The os.Args input shouldn't avoid the argv[0]

[purpleidea]

For the v2/ API, I recommend we accept the full os.Args list, rather than taking off the zeroth argument. Most of the API's out there assume you're passing in the zeroth arg, and I don't know why we should be different.

Furthermore, it would be excellent if the library would actually parse out the zeroth arg. For example, in your top-level args struct, you could do:

type Args struct {
	// XXX: We cannot have both subcommands and a positional argument.
	// XXX: I think it's a bug of this library that it can't handle argv[0].
	Argv0 string `arg:"zeroth"` // some special tag could let it know where to put it

or similar, so that we extract this value correctly.

This changes the behaviour, so I recommend it happen for v2.

Thanks!

[alexflint]

Good suggestion re assuming that the input args include all of os.Args in v2, but I'm not sure about the arg:"zeroth" tag idea -- I think it would be simpler to let people separately access os.Args[0] if/when they need it.

[purpleidea]

Yeah so most importantly is that the Parser should accept all of it, but I think it might be worth considering a mechanism to extract the value too (even though it's trivial) -- this way if you're parsing something, go-arg can be the full API to the CLI and you don't need to separately pass the data out of band. (Remember you might be parsing something.Args instead of os.Args.)