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

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.

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

@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?

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.