Golang 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.

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"]

Comment From: gabyhelp

Related Issues and Documentation

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

Comment From: 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.

Comment From: 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...

Comment From: 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.

Comment From: 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 ?!

Comment From: 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 issues 1 2.

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...

Comment From: seankhliao

This doesn't appear to be a Go bug.

Golang 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.

Go version

Output of go env in your module/workspace:

What did you do?

What did you see happen?

What did you expect to see?

Output of `go env` in your module/workspace: