Start-Process -UseNewEnvironment provides an environment that is missing crucial standard environment variables while not supporting passing a new environment

[mklement0]

On both Windows and Unix platforms, Start-Process -UseNewEnvironment results in an environment that is missing crucial standard environment variables, making the new environment virtually useless, while not providing a mechanism to define a new environment:

• On Windows, -UseNewEnvironment defines only the variables that are explicitly defined, as displayed in System Properties (sysdm.cpl), with crucial, usually automatically defined variables such as $env:ProgramFiles missing, and $env:USERNAME unexpectedly containing SYSTEM.

  • This even prevents another powershell instance from being started this way - see Start-Process fails to launch new powershell.exe instance with -UseNewEnvironment switch #3545 (comment) and below.

• On Unix, an empty environment is essentially passed (with no environment variables defined at all, except $env:PSModulePath).

  • This even prevents invoking any executable by filename only, given that $env:PATH is undefined - see below.

  • While this behavior is similar to POSIX env -i on Unix platforms, the env utility notably includes a mechanism to provide a new environment via name=value pairs, which Start-Process lacks.

---

Possible solutions:

• Repurpose -UseNewEnvironment to not start with a blank slate / crucial variables missing, but to provide the same environment that a shell would see when directly launched by the system (in other words: any environment-variable modifications made by the calling shell would be ignored).

• Additionally, provide a way to pass a custom environment, applied on top of the current or pristine (-UseNewEnvironment) environment:

  • E.g., a new -Environment <hashtable> / -Environment <Collections.DictionaryEntry[]> parameter could be used.

  • If someone truly wanted an empty environment, they could start with $emptyEnv = (Get-ChildItem env:); $emptyEnv | % { $_.Value = $null } and pass -Environment $emptyEnv.

---

The -Environment feature would allow for an - incomplete - approximation of the convenient ad-hoc, command-scoped environment-variable definition feature that POSIX-like shells such as bash offer, where you can prepend one or more name=value pairs to a command:

# Bash (any POSIX-compatible shell)
# Defines $env:FOO as 'bar', but *only for the some-utility child process*.
FOO=bar some-utility 666

Update: #3316 suggests emulating this syntax in PowerShell, which would be the best solution.

The PS approximation would be:

Start-Process -Wait  -Environment @{ FOO = 'bar' } some-utility -Args 666

That said, a crucial limitation is that use of Start-Process makes the external utility operate outside PowerShell's streams, so the only way to provide input / collect output is via the -Redirect* parameters, which requires auxiliary files.

Current behavior

Start-Process -UseNewEnvironment -Wait -NoNewWindow pwsh -args '-Command', 'gci env:; whoami'

• On Windows: PowerShell refuses to start - see Start-Process fails to launch new powershell.exe instance with -UseNewEnvironment switch #3545; note that adding -LoadUserProfile makes no difference.

Internal Windows PowerShell error.  Loading managed Windows PowerShell failed with error 8009001d.

• On Unix: PowerShell starts, lists $env:PSModulePath as the only environment variable - with a seemingly temporary user account's module directory prepended - and the whoami invocation fails, because it cannot be located in the absence of a suitable $env:PATH.

Name                           Value                                                                                                                           
----                           -----                                                                                                                           
PSModulePath                   /tmp/ba38e79f-40c2-440e-ae08-7cf32e0708e1/.local/share/powershell/Modules:/usr/local/share/powershell/Modules:/opt/microsoft/...
whoami : The term 'whoami' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path 
was included, verify that the path is correct and try again.
At line:1 char:21
+ Get-ChildItem env:; whoami
+                     ~~~~~~
    + CategoryInfo          : ObjectNotFound: (whoami:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Environment data

PowerShell Core v6.0.0-beta.5 on macOS 10.12.6
PowerShell Core v6.0.0-beta.5 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.0-beta.5 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.483 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)

[GeeLaw]

On Windows, you should use CreateEnvironmentBlock function to create a complete block of environment variables for a specified user.

There is another issue on UseNewEnvironment. When combined with Credential, it currently starts the subprocess in the new user's context, but with the current user's environment variables, which is surely a bad thing to do. If instead, you turn off UseNewEnvironment and supply Credential, the subprocess will use the default environment block for the specified user, which is likely what the user wants.

[mklement0]

To provide some more insight into what, specifically, is wrong (in addition to the conceptual flaw that @GeeLaw mentions with respect to combining -UseNewEnvironment with -Credential; almost sounds like that combination should be disallowed):

PowerShell/src/Microsoft.PowerShell.Commands.Management/commands/management/Process.cs

Lines 1867 to 1872 in 5fcab21

	if (_UseNewEnvironment)
	{
	startInfo.EnvironmentVariables.Clear();
	LoadEnvironmentVariable(startInfo, Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Machine));
	LoadEnvironmentVariable(startInfo, Environment.GetEnvironmentVariables(EnvironmentVariableTarget.User));
	}

On Unix-like platforms, the LoadEnvironmentVariable() calls are effective no-ops, because Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Machine) and Environment.GetEnvironmentVariables(EnvironmentVariableTarget.User) quietly(!) return an empty hashtable in Unix, where these targets aren't supported (see https://github.com/dotnet/corefx/issues/32685).

In short, LoadEnvironmentVariable() shouldn't even be called to begin with on non-Windows platforms.

As for Windows:

• The original post mentions that crucial built-in variables are missing from the resulting process, which results from the approach of first clearing all variables with

PowerShell/src/Microsoft.PowerShell.Commands.Management/commands/management/Process.cs

Line 1869 in 5fcab21

startInfo.EnvironmentVariables.Clear();

and then only restoring those variables whose definitions are registry-based.
However, there are a number of crucial variables such as %USERPROFILE% that are not registry-based, so they end up missing altogether - see below.

• Also, loading a default $env:PATH value is broken in LoadEnvironmentVariable(), because key access is case-sensitive and the variable name is mistakenly tested for with all-uppercase name PATH:

PowerShell/src/Microsoft.PowerShell.Commands.Management/commands/management/Process.cs

Line 2077 in 5fcab21

if (entry.Key.ToString().Equals("PATH"))

---

For the record, here are the built-in, system-defined environment variables that are not registry-based:

ALLUSERSPROFILE
APPDATA
CommonProgramFiles
CommonProgramFiles(x86)
CommonProgramW6432
COMPUTERNAME
HOMEDRIVE
HOMEPATH
LOCALAPPDATA
LOGONSERVER
ProgramData
ProgramFiles
ProgramFiles(x86)
ProgramW6432
PUBLIC
SESSIONNAME
SystemDrive
SystemRoot
USERNAME    # !! There is a *machine-level* definition with value 'SYSTEM', but there is no *user-level* definition - that is added by the system to the process.
USERDOMAIN
USERDOMAIN_ROAMINGPROFILE
USERPROFILE

Command that generated the list above (with the exception of USERNAME)

gci env: | % name | ? { -not [environment]::GetEnvironmentVariable($_, 'Machine') -and -not [environment]::GetEnvironmentVariable($_, 'User')}

[FranklinYu]

I put the "possible solution 2" in #8352. Even if this issue is fixed by implementing solution 1, I believe solution 2 has other use-cases.

Update: that's a dupe of #3316.

[iSazonov]

I'd deprecate UseNewEnvironment (make alias?) and introduce ClearEnvironment
I like new Environment parameter but can we explicitly say that we add/change variable? Maybe -SetEnvironmentVariable?