PowerShell should support inheritance of default shell environment variables as a default shell

Steps to reproduce

I tried this on OS X

Set powershell as your default shell (so it doesn't inherit your default shell env variables)
Run

> $env:PATH
/usr/bin:/bin

It doesn't have /usr/local/bin in PATH
So I cannot run powershell (and gitk, which really was my motivation)

Expected behavior

/usr/local/bin should be there
powershell should be able to run apps from it, i.e. gitk, powershell

Actual behavior

Cannot run powershell

Environment data

v0.3.0

OS X sets up default paths for shells by calling out to path_helper. Bash (and Zsh, and Csh) all execute

eval `/usr/libexec/path_helper -s`

in their respective /etc/profile files. The OS Xy way for PowerShell to do this would be to add a similar call to our system profile.

However, path_helper was of course not designed with PowerShell in mind, and so it only can emit the PATH and MANPATH variables in two styles, C-shell and Bourne shell. We don't really have much of an option but to parse its output and reinterpret it for PowerShell.

It's easy: string PATH = MANPATH.Replace(':', ';'); :)

Also, it screws up Start-PSBootstrap (on OS X), because it uses installer

vors@Sergeis-MacBook ~/d/fzf> whereis installer
/usr/sbin/installer

Meanwhile, here is a one-liner that you can add to the profile to fix it

$path_helper = /usr/libexec/path_helper; if ($path_helper -match '"(.*)"') { $env:PATH = $Matches[1] }

sergei (@vors)

sergei (@vors) what about MANPATH?

Andy Jordan (@andschwa)

Andy Jordan (@andschwa) ah, what's with it?

Looks like more people are hitting this now. My proposed fix for PS7 is to build on #9528 so if -l is used, pwsh will shell out to sh and apply those env vars to itself. umask and other environment factors will not be taken into account pending additional user feedback and addressed case-by-case.

It looks as workaround without RFC defined PowerShell as login shell. Having the RFC Unix distributive maintainers can expose paths in standard way. Ex.: we could have a ps_path_helper utility per Unix distributive and call it at PowerShell login shell startup.

There is a difference between .bash_profile and .profile
https://askubuntu.com/questions/60218/how-to-add-a-directory-to-the-path/226947

I mean that $PATH can be different for login and non-login shells.

Please review https://github.com/PowerShell/PowerShell-RFC/pull/171/files

Related #10050

Why does pwsh not pick up the environment variables from bash when it is launched??

[mee foo]$ echo $NODE_EXTRA_CA_CERTS
/cafile.pem
[me foo]$ pwsh
PS /foo> $env:NODE_EXTRA_CA_CERTS

Crickets...

Marc (@cawoodm)

Marc (@cawoodm) If you ask about default shell just this was used in #10050.

Ilya (@iSazonov)

Ilya (@iSazonov), Marc (@cawoodm)'s problem is unrelated to this issue.

Marc (@cawoodm), are you sure that $NODE_EXTRA_CA_CERTS is defined as an environment variable (typically created with export), and not just as a shell variable? Shell variables aren't seen by child processes.

Try the following (from Bash or any other POSIX-like shell) to verify that a true environment variable is indeed inherited by PowerShell (this syntax creates a command-scoped environment variable):

$ NODE_EXTRA_CA_CERTS=foo pwsh -noprofile -c '$env:NODE_EXTRA_CA_CERTS'
foo

Also note that such inheritance is a system-level feature that exists independently of PowerShell.

If you have a reproducible case where this inheritance indeed doesn't work, please create a new issue.

To me there is no difference: whatever environment variables I have (echo $foo) should be available in child processes like pwsh. PowerShell should not load some other environment - that would break stuff.

Now, we're using WSL and it does not seem to respect /etc/environment so we have added the following to .bashrc:

NODE_EXTRA_CA_CERTS=foo

To be honest I do not know the difference between bar=foo and export bar=foo...

Checking it with bash:

$ echo $NODE_EXTRA_CA_CERTS
foo

Good, checking it with pwsh:

$ pwsh -noprofile -c '$env:NODE_EXTRA_CA_CERTS'

Not Good.

My expectation would be that the current environment is passed to pwsh. I think this is normal behaviour for child processes.

My expectation would be that the current environment is passed to pwsh

Shell(-only) variables are not part of the system-level process environment, which is the only environment child processes inherit. Shell variables are by design limited to the given shell process.

While in cmd.exe all variables are environment variables, both PowerShell and POSIX-like shells such as bash distinguish between shell(-only) variables and environment variables.

While In PowerShell you always use the same, distinct syntax for both creating and querying environment variables ($env:...), in POSIX like shells both types of variables are queried the same, namely with just the $ sigil, as in $NODE_EXTRA_CA_CERTS; that is when you get a variable value, the syntax isn't telling you whether you're accessing a shell(-only) or an environment variable.

In POSIX-like shells, it's the declaration of a variable that matters:

As a stand-alone statement, NODE_EXTRA_CA_CERTS=foo creates a shell(-only) variable - by design, no child process will see it.

What I used above - prepending variable assignments directly to a command invocation (NODE_EXTRA_CA_CERTS=foo pwsh ....) - is syntactic sugar for defining command-scoped environment variables - only the child process created sees them, not the remainder of the script.

If you want to use a stand-alone statement to create an environment variable, use the export utility:

export NODE_EXTRA_CA_CERTS=foo

In POSIX-like shells:

To see all environment variables, run env (in PowerShell you'd use Get-ChildItem env:)
To check whether a given variable is an environment variable, use typeset -p <name> (works in bash, ksh, zsh): if the output contains either -x or export (zsh), the variable is an environment variable (in PowerShell you'd use Get-Item env:<name>).

Michael Klement (@mklement0)

Thanks Michael Klement (@mklement0) - you da man!

Navigation Menu

Repository navigation

PowerShell should support inheritance of default shell environment variables as a default shell #975

Steps to reproduce

Expected behavior

Actual behavior

Environment data

38 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

PowerShell should support inheritance of default shell environment variables as a default shell #975

Description

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Activity

andyleejordan commented on May 14, 2016

vors commented on May 14, 2016

vors commented on May 15, 2016

vors commented on May 15, 2016

andyleejordan commented on May 16, 2016

vors commented on May 19, 2016

38 remaining items

SteveL-MSFT commented on May 6, 2019

iSazonov commented on May 6, 2019

SteveL-MSFT commented on May 6, 2019

iSazonov commented on Jul 11, 2019

cawoodm commented on Jun 19, 2020

iSazonov commented on Jun 19, 2020

mklement0 commented on Jun 19, 2020

cawoodm commented on Jun 19, 2020

mklement0 commented on Jun 19, 2020

cawoodm commented on Jun 19, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions