Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mklement0 opened this issue Oct 1, 2019 · 6 comments

Comments

@mklement0
Copy link
Contributor

commented Oct 1, 2019

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 PaulHigin/PSThreadJob#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 #10537 (comment)):

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

This comment has been minimized.

Copy link
Collaborator

commented Oct 2, 2019

/cc @SteveL-MSFT Need PowerShell Committee conclusion.

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented Oct 9, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Oct 10, 2019

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

@iSazonov iSazonov added Issue-Meta and removed Issue-Question labels Oct 10, 2019
@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented Oct 10, 2019

@iSazonov the background operator & already uses current working directory, foreach-object -parallel was fixed recently, start-threadjob has PaulHigin/PSThreadJob#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

This comment has been minimized.

Copy link
Collaborator

commented Oct 10, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 10, 2019

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.

@SteveL-MSFT SteveL-MSFT added this to the 7.0-Consider milestone Oct 10, 2019
@iSazonov iSazonov self-assigned this Oct 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.