os: Expand() and ExpandEnv() on Windows don't support Windows style environment variables. :/

[jeffreydwalter]

Please answer these questions before submitting your issue. Thanks!

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

$ go version
go version go1.9.2 darwin/amd64

Does this issue reproduce with the latest release?

yes

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

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/jeff_walter/Code/kace/agent"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.9.2/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.9.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/8w/05w3j5xj4q34m1z6w9ynmcf80000gp/T/go-build022427005=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

Go's os.Expand() and os.ExpandEnv() functions expect variables that start with $ on Windows and not the %WINDIR% style variables, which are native to that platform...

go/src/os/env.go

Line 14 in 8618112

// Expand replaces ${var} or $var in the string based on the mapping function.

[jeffreydwalter]

For example, running the following on Windows:

package main

import (
    "fmt"
    "os"
)

func main() {
    fmt.Println(os.ExpandEnv("$WINDIR is %WINDIR% on Windows."))
}

produces:

C:\WINDOWS is %WINDIR% on Windows.

Which is completely stupid and unexpected for a native Windows person, imho.

Previously discussed: #5177, #8469

[mvdan]

Yes, please see the previous discussions, in particular how the function is working exactly as documented and how there are alternatives like golang.org/x/sys/windows/registry.ExpandString.

I'm going to close this for now. If you have a specific proposal on a change to the os package that is backwards incompatible and reasonable, please feel free to file it. Otherwise, there isn't a bug here.

[jeffreydwalter]

Thanks, I did a search for those functions in the issues history and didn't find them.

[jeffreydwalter]

@bontibon, @mvdan the registry package does NOT solve my problem. I need to expand Windows style environment variable strings using a custom function, with https://golang.org/pkg/os/#Expand because I am launching processes as a specific user in Windows without a shell and need to expand the variables based on that user's environment.

So, my code basically grabs a token from the currently logged in user in Windows, uses that token to get the environment of that user, and then expands from there.

While I appreciate that Windows is clearly an after thought in the os package, and that the documentation covers the expected behavior, the current behavior is pretty idiotic on Windows.

Given the way these functions are written, I don't see a simple backwards compatible change to be made, but how about introducing a new function, ExpandWinEnv() or something like that, that strictly expands %SOMEVAR% style environment variables?

[mvdan]

It seems to me like there's an easier workaround here - simply replacing %FOO% with ${FOO}, and then using os.Expand.

I know this isn't ideal, but this seems like a fairly niche use case and thus not very likely to be included into the os package. Though, you can of course submit a proposal suggesting adding an extra API to it, if you'd like.

[jeffreydwalter]

Yeah, that's what I did. It's just a shame Go sucks so bad for Windows. :/

…

On Tue, May 1, 2018, 10:29 AM Daniel Martí ***@***.***> wrote: It seems to me like there's an easier workaround here - simply replacing %FOO% with ${FOO}, and then using os.Expand. I know this isn't ideal, but this seems like a fairly niche use case and thus not very likely to be included into the os package. Though, you can of course submit a proposal suggesting adding an extra API to it, if you'd like. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24848 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAinB61qL_2-nacEPre1jccp5lVy0zvyks5tuH9ngaJpZM4TT4JM> .