`std::process::Command::env_clear` is unusable on Windows

[meskill]

Followed from the issue that was closed without an actual solution.

Problem

Windows requires some system envs in order to work and be able to run most of the programs and services. Without them they will fail like mentioned here

Possible solution

As described in comments to previous issue rust std could provide that system required envs in order to make env_clear more usable as it has done in libuv and go

[ChrisDenton]

Nominating this for t-libs-api discussion. Some notes:

• The error in the previous issue was caused by an improperly terminated environment block when empty (it was terminating with \0 when it needed to be \0\0). This was fixed.
• The documentation for env_clear says: "...it will prevent the spawned child process from inheriting any environment variable from its parent process".
• It is possible to run Windows executables without any environment variables. However, there are indeed many system functions or even dlls that require at least some. This is an implementation detail and not documented.
• As noted above, Go's equivalent to env_clear makes an exception for SystemRoot. We could do the same.
• Alternatively we could reset the environment to the user's default as suggested here. But this is very far from a "clear" environment so may be better as another method.

[m-ou-se]

@rustbot ping windows

What should Command::env_clear do on Windows? Should it completely clear the entire environment of the about-to-be-spawned process (as on Unix), or should it leave SystemRoot (and perhaps others) alone? Alternatively, should there be an additional method?

[rustbot]

Hey Windows Group! This bug has been identified as a good "Windows candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @albertlarsan68 @arlosi @ChrisDenton @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @nico-abram @retep998 @rylev @sivadeilra @wesleywiser

[dtolnay]

The Go prior art: https://pkg.go.dev/os/exec#Cmd

type Cmd struct {
    ...

    // Env specifies the environment of the process.
    // Each entry is of the form "key=value".
    // If Env is nil, the new process uses the current process's
    // environment.
    // If Env contains duplicate environment keys, only the last
    // value in the slice for each duplicate key is used.
    // As a special case on Windows, SYSTEMROOT is always added if
    // missing and not explicitly set to the empty string.
    Env []string
}

env_clear looks like:

cmd := exec.Command(...)
cmd.Env = []string{}

[waynr]

Something I don't see in the discussion here is reference to this line in the Command::env_clear docs:

Clears all explicitly set environment variables and prevents inheriting any parent process environment variables.

Clears all explicitly set environment variables. It doesn't say anything about clearing all environment variables entirely. It even clarifies further:

This method will remove all explicitly added environment variables set via Command::env or Command::envs.

Doesn't this mean that any variables inherited from the current process's parent process should be left alone? I haven't looked at the implementation at all so I don't know what it actually does on any platform other than Windows.

[ChrisDenton]

I think the second part of the sentence is quite explicit, no:

...and prevents inheriting any parent process environment variables...

In addition, it will prevent the spawned child process from inheriting any environment variable from its parent process.

[waynr]

Doh! Thanks for pointing that out 🤦

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting.

@ChrisDenton made the point that specific DLLs (notably advapi) require this.

Based on our discussion in the meeting, we felt there were two potentially reasonable alternatives:

1. Change the existing method to preserve SYSTEMROOT. This would assume that nobody relies on or cares about fully clearing the environment including this variable.

2. Add a new method (name to be bikeshedded) that acts like env_clear but preserves SYSTEMROOT. This would be the conservative option; the downside would then be having two methods and requiring people to think about which to call.