Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flag: handles unknown arguments in an unexpected less-helpful way #15352

AlexandreZani opened this issue Apr 18, 2016 · 9 comments

flag: handles unknown arguments in an unexpected less-helpful way #15352

AlexandreZani opened this issue Apr 18, 2016 · 9 comments


Copy link

@AlexandreZani AlexandreZani commented Apr 18, 2016

If the flag library encounters an unknown parameter, it discards that parameter and dumps everything else in the positional arguments bucket.

Instead, the flag library should (optionally, probably when ContinueOnError is specified) put all unknown parameters in the positional arguments bucket (returned by Args) and keep attempting to parse the following arguments. (unless encountering something that clearly indicated the beginning of positional arguments such as the naked double-dash "--")

  1. What version of Go are you using (go version)?
    go version go1.3.3 linux/amd64
  2. What operating system and processor architecture are you using (go env)?
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
  3. What did you do?
  4. What did you expect to see?

list == "first", "second", "third"
flagSet.Args() == "--something", "blah"

  1. What did you see instead?
    list == "first", "second"
    flagSet.Args() == "-I", "third", "blah"
    also, Parse printed an error.
@ianlancetaylor ianlancetaylor changed the title flag library handles unknown arguments in an unexpected less-helpful way flag: handles unknown arguments in an unexpected less-helpful way Apr 18, 2016
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Apr 18, 2016
Copy link

@ianlancetaylor ianlancetaylor commented Apr 18, 2016

The flag package can't tell whether an unknown flag takes an argument or not, so to simply continue parsing flags seems risky.

Copy link

@AlexandreZani AlexandreZani commented Apr 18, 2016

I want to make sure I understand your concern correctly:

Let's say the command line looks like this:
--unknown --known foo

The user intends for the value of unknown to be "--known" and "foo" to be a positional argument.
With the current implementation, the flagSet.Args() would return ["--known", "foo"]
With my proposed change, the flag library would put "--unknown" in the list of positional arguments and then set known equal to "foo" which is not what the user wants.

I agree this could be problematic. But it seems unlikely to come up regularly. Most likely, the program will break in a way apparent to the user and they can modify their command line to read
--unknown=--known foo
We could trigger that behavior based on an option set on the FlagSet object.

What about the other half of my proposal? It seems to me at least that flagSet.Arg() should return the first unknown argument instead of only subsequent arguments.

Copy link

@kostya-sh kostya-sh commented Apr 19, 2016

flag package recognizes only the following syntax for flags:

-flag x  // non-boolean flags only

--something doesn't match this syntax so flag package treats it as an argument.

If you change --something to -something in your example you will get "flag provided but not defined: -something" error:

Copy link

@wallrj wallrj commented Jun 27, 2017

I just encountered the same issue where a user supplied a value after a boolean -verbose flag and the remaining flags were ignored.
For example:

Copy link

@josh-tepper josh-tepper commented Jul 6, 2018

+1 -- I was recently writing a small go program that invoked another program with the args that were passed (amongst doing other things). I wanted to parse 2 of the args, but leave the others unchanged. I couldn't use the flag package.

ContinueOnError really means AbortOnError. There is no "real" continue on error

Copy link

@wburningham wburningham commented Oct 4, 2018

@josh-tepper I have a similar situation. What did you end up doing?

Copy link

@josh-tepper josh-tepper commented Oct 5, 2018

@wburningham -- Unfortunately, I ended up doing my own argument parsing


This comment was marked as off-topic.


This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants