flag: Parse eats the double dash inconsistently

[vdemeester]

What version of Go are you using (go version)?

$ go version
1.17.11

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/vincent/.cache/go-build"
GOENV="/home/vincent/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/vincent/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/vincent/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/nix/store/n449plwz10c5l53qhfnrywyns0m8g0qv-go-1.17.11/share/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/nix/store/n449plwz10c5l53qhfnrywyns0m8g0qv-go-1.17.11/share/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.11"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/run/user/1000/go-build1111386722=/tmp/go-build -gno-record-gcc-switches"

What did you do?

With the given go code:

package main

import (
	"flag"
	"fmt"
)

var (
	myflag                  = flag.String("myflage", "", "random flag")
)


func main() {
	flag.Parse()
	fmt.Println(flag.Args())
}

The way the go flag packages act with the -- special argument is inconsistent.

What did you expect to see?

./foo -myflag value -- a b c
[-- a b c]
./foo -myflag value a b c
[a b c]

What did you see instead?

./foo -myflag value -- a b c
[a b c]
./foo -myflag value a b c
[a b c]

This makes it relatively hard to use -- in some cases (aka here, when there is flags and -- and no "non-flag" argument between the two)

[vdemeester]

Additionnal note, this is most likely caused by f.args = f.args[1:] in flag.go (on FlagSet). There is probably a good reason for it but I wonder why we are eating -- in the case (aka, if we just return false, nil instead without mutating f.args it would work as expected).

I also understand that, most likely, this might be an expected behavior — or at least command lines using the package might depend on this particular behavior.

[seankhliao]

This is documented as:

Flag parsing stops just before the first non-flag argument ("-" is a non-flag argument) or after the terminator "--".

"After --" means it's treated as a (special) flag, and thus expected to be consumed.
If you want an additional -- literal argument, you need to pass it again.

Closing as this appears to be working as designed.

[vdemeester]

@seankhliao This is actually a bit tricky.

Flag parsing stops just before the first non-flag argument ("-" is a non-flag argument) or after the terminator "--".

It does not imply (I think) that it should be consumed, as the "first non-flag argument" is not consumed either. Maybe we just need to document it in addition (aka adding somehowe that the "terminator" will be consumed).

[seankhliao]

It says before first non flag argument (so it's not consumed) or after the terminator (so consumed)

[vdemeester]

It says before first non flag argument (so it's not consumed) or after the terminator (so consumed)

Oh thank you @seankhliao, for some reason it did not "click" in my head (the after). All right, it does works as expected by the documentation then.