René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Start-Process -UseNewEnvironment provides an environment that is missing crucial standard environment variables while not supporting passing a new environment","articleBody":"_Update_: \n\n * It seems that in v7.1+ the previously missing env. vars. on Windows are now present (but they'll continue to be missing in _Windows PowerShell_); on Unix-like platforms, the resulting environment is still virtually empty as of v7.5.x.\n\n---\n\nOn 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:\n\n* 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`.\n\n     * This even prevents another `powershell` instance from being started this way - see https://github.com/PowerShell/PowerShell/issues/3545#issuecomment-320699488 and below.\n\n* On Unix, an _empty_ environment is essentially passed (with _no_ environment variables defined at all, except `$env:PSModulePath`).\n\n    * This even prevents invoking any executable by filename only, given that `$env:PATH` is undefined - see below.\n\n    * While this behavior is similar to POSIX [`env -i`](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/env.html) on Unix platforms, the `env` utility notably includes a mechanism to provide a _new_ environment via `name=value` pairs, which `Start-Process` lacks.\n\n---\n\nPossible solutions:\n\n* 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).\n\n* Additionally, provide a way to pass a custom environment, applied _on top_ of the current or pristine (`-UseNewEnvironment`) environment:\n\n   * E.g., a new `-Environment \u003chashtable\u003e`  / `-Environment \u003cCollections.DictionaryEntry[]\u003e` parameter could be used.\n\n    * If someone truly wanted an _empty_ environment, they could start with `$emptyEnv = (Get-ChildItem env:); $emptyEnv | % { $_.Value = $null }` and pass `-Environment $emptyEnv`.\n\n---\n\nThe `-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:\n\n```sh\n# Bash (any POSIX-compatible shell)\n# Defines $env:FOO as 'bar', but *only for the some-utility child process*.\nFOO=bar some-utility 666\n```\n\n_Update_: #3316 suggests emulating this syntax in PowerShell, which would be the best solution.\n\nThe PS approximation would be:\n\n```powershell\nStart-Process -Wait  -Environment @{ FOO = 'bar' } some-utility -Args 666\n```\n\nThat 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_.\n\n\n\nCurrent behavior\n------------------\n\n```powershell\nStart-Process -UseNewEnvironment -Wait -NoNewWindow pwsh -args '-Command', 'gci env:; whoami'\n```\n\n* On Windows: PowerShell refuses to start - see #3545; note that adding `-LoadUserProfile` makes no difference.\n\n```none\nInternal Windows PowerShell error.  Loading managed Windows PowerShell failed with error 8009001d.\n```\n\n* 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`.\n\n```none\n\nName                           Value                                                                                                                           \n----                           -----                                                                                                                           \nPSModulePath                   /tmp/ba38e79f-40c2-440e-ae08-7cf32e0708e1/.local/share/powershell/Modules:/usr/local/share/powershell/Modules:/opt/microsoft/...\nwhoami : 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 \nwas included, verify that the path is correct and try again.\nAt line:1 char:21\n+ Get-ChildItem env:; whoami\n+                     ~~~~~~\n    + CategoryInfo          : ObjectNotFound: (whoami:String) [], CommandNotFoundException\n    + FullyQualifiedErrorId : CommandNotFoundException\n```\n\nEnvironment data\n----------------\n\n```powershell\nPowerShell Core v6.0.0-beta.5 on macOS 10.12.6\nPowerShell Core v6.0.0-beta.5 on Ubuntu 16.04.3 LTS\nPowerShell Core v6.0.0-beta.5 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)\nWindows PowerShell v5.1.15063.483 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)\n```\n","author":{"url":"https://github.com/mklement0","@type":"Person","name":"mklement0"},"datePublished":"2017-08-25T14:06:50.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":34},"url":"https://github.com/4671/PowerShell/issues/4671"}