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

Open
AlexandreZani opened this issue Apr 18, 2016 · 10 comments
Open

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

AlexandreZani opened this issue Apr 18, 2016 · 10 comments
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@AlexandreZani
Copy link

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)?
    GOARCH="amd64"
    GOBIN=""
    GOCHAR="6"
    GOEXE=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GOOS="linux"
    GOPATH="/home/azani/go"
    GORACE=""
    GOROOT="/usr/lib/go"
    GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
    CC="gcc"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
    CXX="g++"
    CGO_ENABLED="1"
  3. What did you do?
    https://play.golang.org/p/44mXvwTfLD
  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
@ianlancetaylor
Copy link
Contributor

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

@AlexandreZani
Copy link
Author

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.

@kostya-sh
Copy link
Contributor

flag package recognizes only the following syntax for flags:

-flag
-flag=x
-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: https://play.golang.org/p/HopM0nOYZu

@wallrj
Copy link

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: https://play.golang.org/p/GPLVZfl2XK

@ALTree ALTree added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jul 18, 2017
@josh-tepper
Copy link

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

@wburningham
Copy link

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

@josh-tepper
Copy link

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

@ORESoftware

This comment has been minimized.

@ianlancetaylor

This comment has been minimized.

mattysweeps added a commit to mattysweeps/go that referenced this issue Mar 2, 2023
…rror handling

Fixes golang#15352

Go's flag.FlagSet struct has ErrorHandling support with three values: ContinueOnError, ExitOnError, and PanicOnError.
ExitOnError and PanicOnError are straightforward, but ContinueOnError stops processing arguments if an error is encountered.

This commit changes the behavior of ContinueOnError to "continue" parsing arguments. Errors are not returned and are silently dropped.
@gopherbot
Copy link

Change https://go.dev/cl/472935 mentions this issue: flag: continue parsing arguments when using ContinueOnError

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants