Set-Location: Match $env:PWD & $PWD on UNIX

[lucyllewy]

PR Summary

Update the UNIX Environment variable PWD to the current location.

PR Context

Fixes #7388

Set the UNIX Environment variable $env:PWD to the full filesystem path
for the current working directory upon Set-Location. This also copes
when the current location is set to a PSDrive. In such circumstances the
environment variable is expanded to the full FileSystem provider path.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
    • Add [feature] to your commit messages if the change is significant or affects feature tests

[kvprasoon]

Casing can be changed .

$path --> $Path and $location --> $Location . Please do the change for all occurrences. Once again, these are not mandatory for the functionality and PR to get merged.

[lucyllewy]

Thanks for the thorough review, @kvprasoon, and for sticking with me while I work through your suggestions :-)

[iSazonov]

I think we can not accept the PR because PowerShell can create many runspaces each of which has its own value of $PWD. Note that .Net also has "pwd" which doesn't correlate with PowerShell $PWD.

[vexx32]

@iSazonov it would be better to set $env:PWD for the current process only, I guess? Is that possible on Unix platforms?

[iSazonov]

for the current process only

@vexx32 PowerShell can create many runspaces/threads in the same process and everyone will export $env:PWD - it is a mess.

[vexx32]

@iSazonov how do other threaded Unix applications handle this issue? Are there any existing applications we could model behaviour from here?

[iSazonov]

@vexx32 $env:PWD is common resource. Let's replace it with Set-Date - what result do you get if many process/threads will modify system time in the same time? I guess Unix uses another scenario - a process track PWD for itself or inform subprocess about work directory.

[lucyllewy]

Using Environment.SetEnvironmentVariable on UNIX will only change the value for the current process and those beneath it in the process tree. You mention multiple run-spaces... how do I start a second run-space within the current pwsh process to test the scenario? (I'm not very familiar with PowerShell yet.)

[vexx32]

An function written in PowerShell that I wrote utilising runspaces can be found here.

The runspace pool is created on line #566, and the separate instances are created and invoked on lines #594-#627

This is a bit of a more complex example as I'm batching the tasks to make the best use of it, but it should illustrate the overall idea. 😄

There may be some already-built functions designed to help test these types of cases in amongst some of the existing test files, but I'm not sure of where to look for those.

[lucyllewy]

OK, run-spaces definitely share the PWD environment, so this PR as it stands is not good-to-go :-)

[lucyllewy]

This needs rethinking, so I'm closing the PR.