flag: ability to ignore unknown flags

[gopherbot]

by mitchell.hashimoto:

The "flag" package currently has three error handling techniques: panic, exit,
and continue. In the face of an unknown flag, the most lenient error handling mechanism
"continue" still returns an error. This is correct behavior. I propose adding
another error handling mechanism or SOME flag to allow unknown flags to be okay (but
report other errors).

The use case I have is that I develop a binary that has many subcommands, like git. E.g.
"git status" "git commit" etc. I have a handful of globally
available flags such as "--debug" "--machine-readable" and others
that I'd love to parse early. Unfortunately, I can't easily with the flag package. By
the time the command is known and further command line flags are setup, it is too late
to parse these.

It would be nice for flag to be able to ignore unknown keys and just do a best-effort
parse. Other types of errors (returned from flag.Value and such) should still be errors.

I imagine this would work best as a new `SetX` method, maybe `SetAllowUnknown` or
something. I defer that to more experienced Gophers.

[gopherbot]

Comment 1 by mitchell.hashimoto:

Sorry, I filed this as a defect when I meant to file as an enhancement. I can't find a
way to modify it now. Sorry!

[cznic]

Comment 2:

Future senario:
I'm dumb and I have passed a wrong (non existing) flag to a command. I expected the flag
to perform something, but I'm using the result of the command (to a file, redirected
stdout) only few (painful/expensive) steps/pipe stages later. Only then I'm surprised
the action was not performed, because the flag I provided was ignored. In the worst case
I've already deleted/overwritten/lost the original source data and cannot go back to
square one.
Today's scenario:
The command fails immediately with writing a problem to stderr and returning a failure
exit code. This saves me from detecting the problem too late.

[gopherbot]

Comment 3 by mitchell.hashimoto:

I absolutely agree with you. I'm not saying to make this a default, just an option.
And my only use case is for multi-pass command-line parsing. I ALWAYS want a bad flag to
fail in the second pass. 
My scenario in your world:
So one of the flags I need in the first pass is "-debug". Let's say the user fat fingers
it and types "-debg". The debug mode won't be enabled because it won't be found on the
first pass. No error occurs. The second pass happens with errors on and then says
"unknown flag -debg. No problem.
Of course the existence of the flag makes it possible for people to shoot themselves in
the foot, but why would people enable it without legitimate reason? If it is off by
default (which I believe it should be), then they would be consciously making that
mistake. There are many ways a programmer can shoot themselves in the foot, but I
believe there are legitimate reasons for it.

[robpike]

Comment 4:

I don't like this proposal but worse, I don't know how to implement it because of
boolean flags. If you don't know the type of the flag, and for an unknown flag you never
know it's type, in general you can't parse the command line.

Status changed to WontFix.