Comment 1:

Which problem does the proposed solution solves? (Assuming ENVVAR="" is not a problem.
Or is it?)

Comment 2 by rks@google.com:

Well, that's application specific. ENVVAR="" is distinct from ENVVAR not existing, and
some applications could not to discriminate between the two. Not to mention, it's nice
to be able to clean up the environment.
For a specific example, we have an application that passes information from one process
to another via the environment. The child process reads the environment, and then (wants
to) clear the key from the environment so that any further children do not have this env
key leaked to them. The best we can do now is set the key to "".

Comment 3:

> For a specific example, we have an application that passes information from one
process to another
> via the environment.
You can filter out environment variables however you'd like with the os/exec API.  Just
set the Cmd.Env as desired.  The default is to inherit your existing process's
environment, but you don't have to do that.
So this bug is only about unsetting an environment variable in the existing process,
which is much less interesting, since the environment isn't a typical way to communicate
within the lifetime of a program.  Typically you just look at the environment once at
start-up.

Comment 4 by rks@google.com:

That assumes that the code that launches the new process is aware of the variable to
remove. But that's not necessarily the case if the code consuming the var is a library.
In our (admittedly uncommon) case, what we have is a library that initializes one of its
packages vars from the environment, and then wants to clear it. The application using
the library may or may not ever do the exec, but our library has no input into this.
What we do now is set it to "", but then the env key leaks to the child processes. We
could clear the env and repopulate it in our library, but then other code looking at the
environment at the same time might see the partially reconstructed environment.

Comment 5:

Labels changed: added priority-later, go1.3, removed priority-triage.

Status changed to Accepted.

Comment 6:

Labels changed: added release-go1.3.

Comment 7:

Labels changed: removed go1.3.

Comment 8:

Labels changed: added repo-main.

Comment 9:

CL https://golang.org/cl/82040044 references this issue.

Comment 10:

Labels changed: added release-go1.4, removed release-go1.3.

Comment 11:

https://golang.org/cl/148370043

Owner changed to @bradfitz.

Status changed to Started.

Comment 12:

CL https://golang.org/cl/148370043 mentions this issue.

Comment 13:

This issue was closed by revision 85cdc49.

Status changed to Fixed.