Command Line Parameters with double quotation marks are not parsed properly by C runtime library used on windows platform by GO, ["TestPassword"] results in [TestPassword]. Quotes filtered out, no escape possible.

[SkybuckFlying]

Go version

go version go1.22.2 windows/amd64

Output of go env in your module/workspace:

Microsoft Windows [Version 10.0.22631.4037]
(c) Microsoft Corporation. All rights reserved.

V:\Go\Tests\test show command line parameters\version 0.02 add c debugging>go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\skybu\AppData\Local\go-build
set GOENV=C:\Users\skybu\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=v:\gopath\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=v:\gopath
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=G:\Tools\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=G:\Tools\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.22.2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=0
set GOMOD=V:\Go\Tests\test show command line parameters\version 0.02 add c debugging\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=G:\Temp\go-build1046575745=/tmp/go-build -gno-record-gcc-switches

V:\Go\Tests\test show command line parameters\version 0.02 add c debugging>

What did you do?

Trying to pass: ["TestPassword"]

Tried all kinds of escape characters. " " Simply gets filtered out resulting in wrong input: [TestPassword]

package main

import (
	"fmt"
	"os"
	"runtime/debug"
)

func main() {
	if len(os.Args) > 1 {
		fmt.Println("Command line arguments:")

		// Store each argument in a separate variable inside the loop
		for i, arg := range os.Args[1:] {
			// Store the current argument in a variable for debugging
			currentArg := arg

			// Print the stored variable for debugging
			fmt.Printf("Argument %d: %s\n", i+1, currentArg)
		}
	} else {
		fmt.Println("No command line arguments provided.")
	}
}

What did you see happen?

Wrong input: [TestPassword]

What did you expect to see?

["TestPassword"]

[gabyhelp]

Related Issues and Documentation

• os.Args is missing/eating/interpreting double quote on Windows #30952 (closed)
• `os.Args` parsing with quotes is somehow incorrect on Windows platform #42443 (closed)
• syscall/exec_windows.go: appendEscapeArg does not escape all necessary characters #68313 (closed)
• os: commandLineToArgv() does not correctly parse argv[0] in Windows #50028
• os/exec: extraneous quote escaping in argument received by spawned program, on Windows #21739 (closed)
• cmd/go: `go env` incorrect quoting for values with double quotes #58855 (closed)
• flag: fails to parse flags with particularly-placed (but valid) double-quotes inside executable path #43054
• affected/package: #61780 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[SkybuckFlying]

Hopefully fixed soon. This is preventing me from experimenting/developing with ViteLabs vite blockchain project on Microsoft Windows. Posted this comment right after above comment, reading above comment...

My problem is not related to powershell, but cmd.exe where I would like to run: govite command line parameters.

Strangely enough:

["Test"]

Now works in my test program, have not tested it yet with this particular go test program.

I believe what may be happening is that this bug may have been fixed in some go version.

And the vitelabs govite exe might have been compiled/build with an older version still containing the bug.

I will try re-building govite and see if this fixes the problem.

[SkybuckFlying]

For what it is worth here is go.mod from this vitelabs vite project:

module github.com/vitelabs/go-vite/v2

go 1.13

require (
	github.com/BurntSushi/toml v0.3.1 // indirect
	github.com/StackExchange/wmi v0.0.0-20180116203802-5d049714c4a6 // indirect
	github.com/aead/ecdh v0.2.0
	github.com/allegro/bigcache v1.2.1
	github.com/davecgh/go-spew v1.1.1
	github.com/deckarep/golang-set v1.7.1
	github.com/go-ole/go-ole v1.2.1 // indirect
	github.com/go-stack/stack v1.8.0
	github.com/golang-collections/collections v0.0.0-20130729185459-604e922904d3
	github.com/golang/mock v1.6.0
	github.com/golang/protobuf v1.5.2
	github.com/golang/snappy v0.0.4
	github.com/hashicorp/golang-lru v0.5.5-0.20210104140557-80c98217689d
	github.com/kr/pretty v0.1.0 // indirect
	github.com/mattn/go-colorable v0.1.8
	github.com/mattn/go-isatty v0.0.13
	github.com/patrickmn/go-cache v2.1.0+incompatible
	github.com/pkg/errors v0.9.1
	github.com/rs/cors v1.8.0
	github.com/shirou/gopsutil v3.21.7+incompatible
	github.com/stretchr/testify v1.7.0
	github.com/syndtr/goleveldb v1.0.1-0.20210305035536-64b5b1c73954
	github.com/tklauser/go-sysconf v0.3.5 // indirect
	github.com/tyler-smith/go-bip39 v1.1.0
	github.com/vitelabs/go-vite v2.10.2+incompatible // indirect
	go.uber.org/atomic v1.9.0
	golang.org/x/crypto v0.0.0-20210711020723-a769d52b0f97
	golang.org/x/net v0.0.0-20210805182204-aaa1db679c0d
	golang.org/x/sys v0.0.0-20210809222454-d867a43fc93e
	google.golang.org/protobuf v1.27.1
	gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127 // indirect
	gopkg.in/natefinch/lumberjack.v2 v2.0.0
	gopkg.in/natefinch/npipe.v2 v2.0.0-20160621034901-c1b8fa8bdcce
	gopkg.in/urfave/cli.v1 v1.20.0
)

Maybe this can prove it's using an old enough version of go to be a problem, if so this go.mod needs updating to new version and hope all compiles well... investigating...

[SkybuckFlying]

I tried to replicate problem by changing go.mod of my test project to same version as this vitelabs vite go version:
from go 1.22.2 to go1.13

However I was unable to re-create the problem. Strange.

[SkybuckFlying]

Only thing I can think of is that C runtime library got updated... because of my experiments, that could explain why it's now fixed... or there is a bizar threading/race condition issue but I don't think so... so changing go versions might not be enough to replicate ancient behaviour, if true another bad sign for GO language.

The correct way would have to be replace C runtime library that GO or LiteIDE uses with an older one.

But at this point I am lost, I do not want to get involved in ancient C garbage, I came here for GO, not old messy C never building mess with missing make crap on windows, had enough of that.

Even with make installed from gnuwin C builds usually still fail somehow on windows, maybe this is one of the reasons why, don't know, for my open source C written on Linux is dead to me, a big waste of time.

If it's working for you great, anyway for now I consider this issue somewhat solved, but I have no idea how it was solved for sure. Except this mysterious C runtime library update hypothesis. For that reason I will leave this open, until somebody can confirm what the reason is why it's suddenly working.

Can you re-produce the failure ?! and prove this hypothesis ?!

[SkybuckFlying]

Another hypothesis why it might have worked this time:

It could be that C runtime library was already loaded into memory because LiteIDE was running and windows did not re-load the older C runtime library, because of library memory sharing/DLL runtime behaviour.

While co-pilot confirms this hypothesis is possible for DLLs, GOLANG does not seem to rely on DLLs on Windows, not entirely sure though bot could be wrong:

"
Yes, it’s possible for old bugs to disappear due to DLL (Dynamic Link Library) runtime memory sharing on Windows. Here’s how it can happen:

DLL Memory Sharing: When multiple applications use the same DLL, they share the same memory space for that DLL. If an older application had a bug due to a faulty DLL, and a newer version of the DLL is loaded into memory by another application, the older application might benefit from the bug fixes in the newer DLL.

DLL Replacement: If the system or another application updates the DLL to a newer version, the older application might use this updated DLL when it restarts, potentially resolving the bug.

Runtime Behavior: The behavior of applications can change at runtime based on the DLLs they load. If a newer DLL with bug fixes is loaded, the application might exhibit different (and correct) behavior.

However, this scenario can also lead to DLL Hell, where conflicting versions of DLLs cause unpredictable behavior. It’s generally better to ensure that each application uses the correct version of its required DLLs to avoid such issues12.

If you have any specific issues or need further assistance, feel free to ask!
"

and

"
Go (Golang) itself doesn’t have specific DLLs that it relies on, as it is designed to be a statically compiled language. This means that when you compile a Go program, all the necessary code is included in the executable, rather than relying on external DLLs. However, Go programs can interact with Windows DLLs using the syscall package or the golang.org/x/sys/windows package.
"

I searched GO installation folder, no DLLs there, also GOPATH no DLLs there...

So I doubt this hypothesis for now, probably static linked library...

[seankhliao]

This doesn't appear to be a Go bug.