cmd/go: setting the User or System Environment Variables

[akhilravuri1]

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

$ go version
go version go1.10.3 windows/amd64

Does this issue reproduce with the latest release?

NO

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

go env Output

set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\rakhil\AppData\Local\go-build
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\rakhil\go
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\rakhil\AppData\Local\Temp\go-build179340394=/tmp/go-build -gno-record-gcc-switches

What did you do?

package main

import (
"fmt"
"os"
"path"
)

func main(){
a := os.Getenv("GOPATH")
base := path.Join(a,"/src/github.com/ibmdb/go_ibm_db")
fmt.Println(base)
os.Setenv("CGO_LDFLAGS",base)
fmt.Println(os.Getenv("CGO_LDFLAGS"))
}

What did you expect to see?

CGO_LDFLAGS will be updated.

What did you see instead?

Nothing has been changed in that Env Variable

[agnivade]

Please tell us what you did exactly.

[akhilravuri1]

I was trying to set the environment variables from the Go program.

[bcmills]

Please provide a concrete list of commands that we can run to reproduce the problem, along with the output you observed from those commands.

[akhilravuri1]

package main

import (
"fmt"
"os"
"path"
)

func main(){
a := os.Getenv("GOPATH")
base := path.Join(a,"/src/github.com/ibmdb/go_ibm_db")
fmt.Println(base)
os.Setenv("CGO_LDFLAGS",base)
fmt.Println(os.Getenv("CGO_LDFLAGS"))
}

[agnivade]

Can you show us the output you are getting ? I am failing to reproduce the issue here.

[akhilravuri1]

The code works fine. But when I check for the CGO_LDFLAGS in user or system variables, I did not find it.

[AlexRouSg]

os.Setenv does not set the user or system variables. It only sets the variables for the current process/program.

If you want to set the user or system variables you need admin permissions and you need the Windows API.

[akhilravuri1]

Can we set it from exec.Command() function?

[akhilravuri1]

I have created a package when the user does go get command, I want a go file to run automatically so that it can set environmental variables.

Can we run a file in golang when the user downloads the package?

[AlexRouSg]

Can we set it from exec.Command() function?

You can try the setx command but you still need admin permissions.
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/setx

As this is not a bug, I suggest you ask for further help in one of the places listed in https://github.com/golang/go/wiki/Questions

Or maybe even https://social.msdn.microsoft.com/Forums/en-US/home

Can we run a file in golang when the user downloads the package?

No, if you want that you need to make your own downloader/installer

[akhilravuri1]

If we create a package in node we can do that if the user downloads a package using npm. (Run a file after package gets downloaded)

Is it a backlog in golang?

[agnivade]

Is it a backlog in golang?

This was raised before and closed. Please see #15536.

Specifically this comment -

We don't want arbitrary command to run when you simply go get a package (even go build doesn't run arbitrary commands.)

If you think you have a use case which might be beneficial to others, please feel free to open a proposal issue laying out the requirements and your proposed outline. Please note that there are other places too where Go differs from npm style package install. For eg- there is no concept of devDependencies in a go.mod and that is intentional because we do not want to make the developer learn more concepts. The recommended approach for that is https://github.com/golang/go/wiki/Modules#how-can-i-track-tool-dependencies-for-a-module.

It sounds like the current issue is resolved anyways. So closing this.