POSIX mandates the presence of an environment variable named PWD that should "represent an absolute pathname of the current working directory."

That is, POSIX-like shells keep the value of this env. variable in sync with their working dir. so that (non-shell) processes created from the shell can rely on it reflecting the shell's notion of the current dir.

PowerShell currently doesn't set this environment variable (it only sets its internal automatic $PWD variable, which other processes cannot see), which can have unintended consequences when invoking Unix utilities that rely on it.

This problem is conceptually related to #3428, for which there is no good solution due to its in-process nature.

In the case at hand, however, since a child process must be created to invoke an external program, it should be possible to add a PWD environment variable reflecting PowerShell's current filesystem location to the environment block of the new process.

Steps to reproduce (on macOS or Linux)

# Switch to an arbitrary location and make the Perl process display the value of $env:PWD
Set-Location /tmp; perl -le 'print $ENV{PWD}'  

Expected behavior

/tmp

That is, the external utility's process should see PowerShell's current filesystem location in its PWD environment variable.

(Note that using another shell (e.g., bash) for this test wouldn't be a valid test, because POSIX-like shells set the PWD environment variable themselves.)

Actual behavior

/home/jdoe     # e.g.

Even with PowerShell configured as the user's default shell, $env:PWD is still set at the time the PowerShell session starts, and seemingly always reflects the user's home dir.

Environment data

PowerShell Core v6.1.0-preview.4 on macOS 10.13.6
PowerShell Core v6.1.0-preview.4 on Ubuntu 16.04.4 LTS