Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os: ExpandEnv not expanding windows environment variables #8469

Closed
gopherbot opened this issue Aug 4, 2014 · 11 comments
Closed

os: ExpandEnv not expanding windows environment variables #8469

gopherbot opened this issue Aug 4, 2014 · 11 comments

Comments

@gopherbot
Copy link

by sverre.bakke:

os.ExpandEnv will expand/resolve unix style environment variables based on the $var or
${var} style. However, on Windows, environment variables uses %var% as format instead.
This means that when writing Windows code, strings that refer to environment variables
(e.g. from configuration files, registry, or even other environment variables) will need
to be either converted to unix style environment variables before expanding or have to
be manually expanded.

Go should have a Windows spesific version of the ExpandEnv() function that will use
Windows style expansions instead of Unix style expansions.

Golang currently uses the following format for all operating systems:
fmt.Println(os.ExpandEnv("${systemroot}\\test"))

The correct way on windows is as follows:
fmt.Println(os.ExpandEnv("%systemroot%\\test"))
@gopherbot
Copy link
Author

Comment 1 by sverre.bakke:

I have attached a proposed Windows version based on the existing one.

@gopherbot
Copy link
Author

Comment 2 by sverre.bakke:

Sorry about that, the captcha removed the attachment, trying again.

Attachments:

  1. proposed_change.txt (532 bytes)

@ianlancetaylor
Copy link
Contributor

Comment 3:

To send changes, please use the contribution process described at
http://golang.org/doc/contribute .  A change of this sort should be discussed on the
golang-dev list first.

Labels changed: added repo-main, release-none, os-windows.

@bradfitz bradfitz removed the new label Dec 18, 2014
@mattn
Copy link
Member

mattn commented Feb 16, 2015

If sverre.bakke don't do about this, I'll do. Is it okay?

@alexbrainman
Copy link
Member

@mattn
Copy link
Member

mattn commented Feb 16, 2015

os.Expand allow to be given mapping function. so I'm thinking we must keep the codes which is substituting envs with % as sverre.bakke suggested.
Eventhough, if we don't make different behavior to os.ExpandEnv. So I will just apply the change sugguested in above.

@mattn
Copy link
Member

mattn commented Feb 16, 2015

Hmm, os.Expand on windows will be degladed because $* or $$ will not work with my change.
@alexbrainman How do you think?

@minux
Copy link
Member

minux commented Feb 16, 2015 via email

@mattn
Copy link
Member

mattn commented Feb 17, 2015

@rsc rsc removed the os-windows label Apr 10, 2015
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@sbakke
Copy link

sbakke commented Jun 18, 2015

Sorry, I forgot all about this one. I just used the code I provided earlier in my own project. I understand that its difficult to change the current behaviour, but I suggest that some version of this is added in Go 2.0 when the time comes. I guess, as discussed, the whole api might need a refresh at some point. For now, anyone that need it can just google and find this discussion with working code to use in their own project. Since most of it is ripped from the Golang standard library anyway, the attached code has the same license as the Go standard library and is in my opinion fully owned by the Golang developer team; crossing my fingers and hoping that some version of this is included in the standard library at some point :)

@mattn thanks for pushing this discussion :)

@alexbrainman
Copy link
Member

I think you could use golang.org/x/sys/windows/registry.ExpandString instead.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants