cmd/go: flags ending with "=." is not correctly parsed by go tool when run via powershell

[maruel]

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

$ go1.15.6 version
go version go1.15.6 windows/amd64

Does this issue reproduce with the latest release?

Yes. Reproduces on go1.13.0 too so it's been like that for a while.

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

go env Output

$ go1.15.6 env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\parent\AppData\Local\go-build
set GOENV=C:\Users\parent\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\parent\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\parent\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Users\parent\sdk\go1.15.6
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Users\parent\sdk\go1.15.6\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\parent\AppData\Local\Temp\go-build176809342=/tmp/go-build -gno-record-gcc-switches

What did you do?

git clone https://github.com/maruel/go-bench-recursive-bug
cd go-bench-recursive-bug
go1.15.6 test -bench=. ./...
go1.15.6 test -count=1 ./...

Tested https://github.com/maruel/go-bench-recursive-bug at commit maruel/go-bench-recursive-bug@4b4c223

The tree looks like:

• go.mod
• v1/
  • bench.go
  • bench_test.go
• v2/
  • bench.go
  • bench_test.go

There is no .go file in the directory containing go.mod. The test files do not contain a benchmark.

See github action at https://github.com/maruel/go-bench-recursive-bug/blob/4b4c22328a366372765134a10c77900a48605d6a/.github/workflows/test.yml#L56. When shell is not set, it defaults to powershell on Windows. I reproduce locally so it is not github specific.

Here's an example test run to save you from testing locally: https://github.com/maruel/go-bench-recursive-bug/actions/runs/421285187

Ignore the ".\..." I was just experimenting.

What did you expect to see?

In macOS, linux, Windows 10 on cmd:

go1.15.6 test -bench=. ./...
PASS
ok      github.com/maruel/go-bench-recursive-bug/v1     0.309s
PASS
ok      github.com/maruel/go-bench-recursive-bug/v2     0.308s

go1.15.6 test -count=1 ./...
ok      github.com/maruel/go-bench-recursive-bug/v1     0.296s
ok      github.com/maruel/go-bench-recursive-bug/v2     0.568s

What did you see instead?

Windows 10 in powershell only:

go1.15.6 test -bench=. ./...
no Go files in C:\Users\parent\src\go-bench-recursive-bug

go1.15.6 test -count=1 ./...
ok      github.com/maruel/go-bench-recursive-bug/v1     0.310s
ok      github.com/maruel/go-bench-recursive-bug/v2     0.576s

[bcmills]

The error message you're getting from go test is what you would get if you passed . as a positional argument

Compare on Linux:

go-bench-recursive-bug$ pwd
/tmp/tmp.KALKdsjINS/go-bench-recursive-bug

go-bench-recursive-bug$ go test -bench= . ./...
no Go files in /tmp/tmp.KALKdsjINS/go-bench-recursive-bug

(Note the extra space after -bench= in that invocation.)

@maruel, can you confirm that the command line you tested with does not contain any Unicode whitespace after the = token?

If you run the program in https://play.golang.org/p/CknqiPUEKR9 using go run main.go -bench=. in PowerShell, what arguments does it print?

[maruel]

https://github.com/maruel/go-bench-recursive-bug/blob/ca0741b30bcc6c61c398d85d85a4cf3648b19e9e/.github/workflows/test.yml#L57

The same string go test -bench=. ./... is used on all OSes.

Your comment made me realize that this works on powershell:

go test -bench . ./...
PASS
ok      github.com/maruel/go-bench-recursive-bug/v1     0.301s
PASS
ok      github.com/maruel/go-bench-recursive-bug/v2     0.295s

So -bench . works but -bench=. doesn't, and this distinction only exists on powershell.

Here's the confirmation:
https://github.com/maruel/go-bench-recursive-bug/runs/1552580624?check_suite_focus=true

And your suspicion is right.

Powershell:

go run main.go -bench=.
["C:\\Users\\parent\\AppData\\Local\\Temp\\go-build894726910\\b001\\exe\\main.exe" "-bench=" "."]
go run main.go "-bench=."
["C:\\Users\\parent\\AppData\\Local\\Temp\\go-build425756990\\b001\\exe\\main.exe" "-bench=."]
go run main.go -bench=. -foo=bar
["C:\\Users\\parent\\AppData\\Local\\Temp\\go-build535392258\\b001\\exe\\main.exe" "-bench=" "." "-foo=bar"]
go run main.go -bench=. -foo=.
["C:\\Users\\parent\\AppData\\Local\\Temp\\go-build471980682\\b001\\exe\\main.exe" "-bench=" "." "-foo=" "."]
go run main.go -bench=a
["C:\\Users\\parent\\AppData\\Local\\Temp\\go-build201397402\\b001\\exe\\main.exe" "-bench=a"]

cmd:

go run main.go -bench=.
["C:\\Users\\parent\\AppData\\Local\\Temp\\go-build817999182\\b001\\exe\\main.exe" "-bench=."]
go run main.go "-bench=."
["C:\\Users\\parent\\AppData\\Local\\Temp\\go-build207076590\\b001\\exe\\main.exe" "-bench=."]

So it looks like it's a parsing bug somewhere in the intersection of go and powershell but I can only confirm with a argument ending with "=.". I'm not familiar enough with powershell to know where the bug is located.

That seem surprising to me that nobody used any form of -foo=. in go with powershell yet and would have not noticed the problem.

$PSVersionTable.PSVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      19041  610

[bcmills]

@4a6f656c @alexbrainman @networkimprov @mattn and any other folks who may know things about PowerShell: is it expected that -bench=. in PowerShell expands to -bench= and . as separate arguments?

[seankhliao]

I think it's this bug in powershell PowerShell/PowerShell#6291

[maruel]

Thanks Sean, that's it.

I confirmed that it works with the compiled program @bcmills noted above, not just via "go ...". And confirmed that -foo.bar is split up as "-foo" and ".bar". "=" is not needed.

Since it's truly a bug in powershell, we can close this one as there is no AI.