env_clear does not work on Windows

[nagisa]

Running Command with env_clear will reproducibly result in Error with OS code 87.

> cargo script -e '::std::process::Command::new(\"gcc.exe\").env_clear().output(
).unwrap()'
   Compiling expr v0.1.0 (file:///C:/Users/drk/AppData/Local/Cargo/script-cache/
expr-37b14ef2470ffe18)
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Error
{ repr: Os { code: 87, message: "The parameter is incorrect." } }', ../src/libco
re\result.rs:688
An unknown error occurred

if env_clear is omitted, it works:

To learn more, run the command again with --verbose.
> cargo script -e '::std::process::Command::new(\"gcc.exe\").output().unwrap()'
   Compiling expr v0.1.0 (file:///C:/Users/drk/AppData/Local/Cargo/script-cache/
expr-67fa84126914720e)
Output { status: ExitStatus(ExitStatus(1)), stdout: "", stderr: "gcc.exe: fatal
error: no input files\r\ncompilation terminated.\r\n" }

[alexcrichton]

This is expected behavior because it appears that there are basically some required environment variables on Windows to get subprocesses to work.

For example libuv has an explanation of this and a list of required variables which seems to match cygwin's list of required variables as well

[nagisa]

Should we ensure that on windows we pass these variables through regardless of env_clear being specified? Otherwise, we should at least document this behaviour.

[alexcrichton]

Perhaps yeah. In the past our spawning tended to mirror libuv closely (where it all originated from), but we've since backpedaled a bit from that original design. From a systems-y perspective I would prefer that env_clear actually clear the environment, but from a "let's make this ergonomic to use" perspective it'd make more sense to only clear non-required environment variables.

I'd probably personally be fine either way

[retep998]

CreateEnvironmentBlock is used to create a new environment block. If FALSE is passed for bInherit then the returned block will "start from a clean state". If we're going to preserve a few required environment variables, might as well get them straight from the system rather than inheriting them.

[alexcrichton]

Sounds reasonable to me!

[Mark-Simulacrum]

I feel like this isn't a change we can make backwards compatibly. What are the considerations that are involved in making this change? Can we make it? We at least need documentation for this inconsistency, but I'm not sure what tag to use for those issues: T-doc?

[alexcrichton]

I think we've got leeway to change the implementation on Windows to preserve some environment variables. If a process can just literally not be spawned without an environment variable then we're basically guaranteed to not break anyone if we start preserving it by default on env_clear. Existing working code would override it anyway (as it'd specify a value for the variable)

[sanmai-NL]

See the discussion in PowerShell/PowerShell#4671.

[meskill]

The issue is closed, but with the fix related to running process on windows with empty environment that seems not quite exactly as described previously

Using env_clear on windows is still unusable in most cases and leads to the cryptic errors like this

[ChrisDenton]

Can you open a new issue?