-
Notifications
You must be signed in to change notification settings - Fork 18k
flag: fails to parse flags with particularly-placed (but valid) double-quotes inside executable path on windows #43054
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
Comments
For some more context, this only happens with cmd.exe The terminal interprets |
I do not believe this statement is correct. It may be true in powershell, but it is definitely not true in cmd.exe which has no problem finding and executing the binary. If it was true, then the OS would be looking for a file called This behavior is, I believe, documented at https://docs.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?redirectedfrom=MSDN&view=msvc-160 (my emphasis added): The first argument (argv[0]) is treated specially. It represents the program name. Because it must be a valid pathname, parts surrounded by double quote marks (") are allowed. The double quote marks aren't included in the argv[0] output. The parts surrounded by double quote marks prevent interpretation of a space or tab character as the end of the argument. The later rules in this list don't apply. It is only in a "later rule"-- which explicitly does not apply to argv[0]-- that it then states: "A double quote mark preceded by a backslash (\") is interpreted as a literal double quote mark (")." Even if this is a known issue that will not be fixed, I have to disagree with the suggestion that this isn't a bug. "my program is running and it cannot find the flags I passed to it" is a bug, regardless of what the technical reasons are for it existing. It would be a different thing if Windows itself interpreted it the way you've suggested, and therefore windows was unable to find and execute the exe. However, that is not the case. |
BTW I recognize that the bug may not from the flags lib directly-- based on your comment that os.Args is |
Thanks for the link to the docs. ping as per os owners @rsc @robpike @ianlancetaylor @bradfitz @griesemer |
What version of Go are you using (
go version
)?go version go1.15.2 darwin/amd64, cross-compiling for and running on win
I noticed this issue after cross-compiling for win, then running on win. I have only been able to reproduce on Win. I have not tried compiling natively on win to see if the issue also exists under those circumstances
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?Host (build):
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mattewong/Library/Caches/go-build"
GOENV="/Users/mattewong/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/mattewong/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/mattewong/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/3d/4_23s9qj7dj3z966y7_q__hm0000gp/T/go-build380736401=/tmp/go-build -gno-record-gcc-switches -fno-common"
Target (run): Windows Server 2016
What did you do?
flag_bug.go:
compile:
GOOS=windows go build flag_bug.go
copy flag_bug.exe to target system c:\temp\
run:
What did you expect to see?
Same result each time: usage
What did you see instead?
First 2 behave as expected:
However, the third one (
"c:\temp\"flag_bug.exe -h
) does not:It appears that the double-quotes somehow cause the flag parsing to entirely fail, and no flags are parsed (whether expected flags or not)
The text was updated successfully, but these errors were encountered: