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

[AlexandreZani]

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]

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

[AlexandreZani]

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]

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]

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

[josh-tepper]

+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]

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

[josh-tepper]

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

[gopherbot]

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