PowerShell should set its CWD on *nix

[rjmholt]

Discussing this with @TylerLeonhardt.

A number of applications and utilities use the process CWD information provided by the OS to do useful things. For example iTerm2 can follow your shell session's CWD in the title.

I feel like there has been discussion of this before but can't provide it anywhere, so opening an issue.

My proposal is:

• PowerShell has multiple runspaces, each of which can be in a different location at the same time
• Therefore PowerShell should expose its CWD as the location of runspace 1, since this is very likely to be the interactive runspace
• This should be available as a simple API internally that is a no-op on other runspaces, and it should be executed beside whatever changes PowerShell's own concept of CWD.

[rjmholt]

For reference, this is an ask to implement chdir calls when runspace 1 changes its working directory. .NET Core exposes it as Directory.SetCurrentDirectory().

[TylerLeonhardt]

There are a lot of reasons why having this would be good. Pretty much every terminal emulator on non-Windows relies on CWD. Here are some that I wish I could take advantage of:

In iTerm2:

This bullet uses CWD when creating a new tab so that the new tab is in the same directory as the previous tab:

(Note: Hyper does the same thing)

The git branch in the status bar at the top uses the CWD to search for a .git folder to see what branch you're on:

There are many other examples across multiple terminal emulators on non-Windows. Using CWD seems to be the way to integrate a rich terminal experience.

[TylerLeonhardt]

btw, I attempted to fix this a while back - https://github.com/PowerShell/PowerShell/pull/6824

I like the addition of having it only apply to Runspace 1

[iSazonov]

cons - there is nested prompts.

[TylerLeonhardt]

@iSazonov please elaborate on why that is a con. If you go into a nested prompt, you are still in the same Runspace (Runspace 1) and I would expect CWD changes to be reflected in that nested prompt.

[rjmholt]

Had an email thread about this today and just want to write up some arguments against this:

• There’s no formal definition of the canonical runspace, and runspaces can be created and closed on the fly. So setting CWD based on one of them is slightly arbitrary.
• The current CWD setting is the .NET default of “the directory where the process was started”, which is also useful information
• The existing behaviour has been in for some time, and breaking it could cause issues