Powershell: Make the current location for script blocks executing in background/thread jobs default to the caller's in all scenarios

[mklement0]

Update: This proposal has been approved - the remaining work is summarized in this comment.

---

Ideally, we'd have a _consistent_ experience across _all_ background-/thread-job related features, meaning that all of the following should exhibit the same behavior with respect to the current location that the script block being passed sees (by default:

• (a) Start-Job
• (b) Start-ThreadJob
• (c) postpositional & to start a job (implicit Start-Job)
• (d) ForEach-Object -Parallel

The most sensible location to use is the _caller's_ current location, which (c) already uses and (d) will, once #10672 is merged.

The proposal is to make (a) and (b) behave like (c) and (d) for overall consistency and use of a sensible default:

(b) (Start-ThreadJob) was _meant_ to be modeled after Start-Job's example, but currently isn't: it uses the - virtually unpredictable from a user's perspective - process-wide working directory; given that, it shouldn't be too late to change it - see https://github.com/PaulHigin/PSThreadJob/issues/46

(a) (Start-Job) regrettably has always defaulted to $HOME (the filesystem provider's home location).

The question now is:

Can we consider Start-Job's default-to-$HOME behavior a bug / something worth fixing as a Bucket 3: Unlikely Grey Area change?

I'm certainly personally in favor of that, but I haven't looked into how likely it is that existing Start-Job code relies on $HOME to be the default directory.

@iSazonov's take (from his comment at https://github.com/PowerShell/PowerShell/issues/10537#issuecomment-536199173):

I suggest to consider Start-Job case as _bug_.
If my work folder is c:\work and I run a job which switched to $home that is c:\users\isazonov - the last place is the worst place where user would like to see a resulting file. We could guess that user would use relative path to Documents folder. But most likely when faced with this inconsistency, the user will use the exact path to the working directory (c:\work), especially since the job is perceived as some kind of background process.

[iSazonov]

/cc @SteveL-MSFT Need PowerShell Committee conclusion.

[SteveL-MSFT]

@PowerShell/powershell-committee discussed this, we agree that each of these should standardize on using the current working directory as the working directory. Start-Job is already inconsistent with itself in that Linux/macOS starts in user's home directory, but on Windows it starts in user's Documents folder. We agree to accept a breaking change to always start in the filesystem current working directory where the cmdlet/operator is used for all of the scenarios.

[iSazonov]

@mklement0 Please update the issue description with current status - what is left to fix after last commits? May be add links to PRs.

[SteveL-MSFT]

@iSazonov the background operator & already uses current working directory, foreach-object -parallel was fixed recently, start-threadjob has https://github.com/PaulHigin/PSThreadJob/issues/46 opened and @PaulHigin can make that fix and we can include that version in PS7. I believe just Start-Job needs a fix.

[iSazonov]

@SteveL-MSFT Yes. The issue has PowerShell Committee conclusion and I'd want to see all (problems and solutions) in the OP for clear history because it is a breaking change.

[mklement0]

I've updated the OP with a note at the top that points to the approval comment and to Steve's follow-up comment summarizing the remaining work needed.

[MathiasMagnus]

I'd consider ForEach-Object -Parallel to be special in the sense that it's not a breaking change, since it's only a preview feature. This was the case I hit where my code was using old-school ForEach-Object and moving to the parallel version broke because executables were not found by the script. In this sense, not applying the caller's cwd _is_ the breaking part.

[PaulHigin]

@MathiasMagnus
This has already been fixed for ForEach-Object -Parallel (#10672)

[mklement0]

@MathiasMagnus: Also note that it will be fixed for Start-Job and Start-ThreadJob as well (despite being technically breaking changes).

[msftbot[bot]]

This issue has been marked as fixed and has not had any activity for 1 day. It has been closed for housekeeping purposes.