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: Parse eats the double dash inconsistently #53691

Closed
vdemeester opened this issue Jul 5, 2022 · 5 comments
Closed

flag: Parse eats the double dash inconsistently #53691

vdemeester opened this issue Jul 5, 2022 · 5 comments

Comments

@vdemeester
Copy link

vdemeester commented Jul 5, 2022

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
Copy link
Author

vdemeester commented Jul 5, 2022

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
Copy link
Member

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.

@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Jul 5, 2022
@vdemeester
Copy link
Author

@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
Copy link
Member

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

@vdemeester
Copy link
Author

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.

@golang golang locked and limited conversation to collaborators Jul 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants