Start-Job needs a -WorkingDirectory parameter

Currently, Start-Job:

• defaults to different, fixed working directories on different platforms (which is problematic in itself):

  • $HOME on Unix (macOS, Linux)
  • $HOME\Documents on Windows

• by contrast, using the newly-introduced Unix-like ... & syntax defaults to the current location; this discrepancy is problematic too [update: but as designed] - see #4267

Either way, there is no simple way to have the caller set the working directory explicitly, leading to such painful workarounds as in this SO answer.

The proposed solution:

# Wishful thinking
> $jb = Start-Job -WorkingDirectory $PSHOME { "Hi from $PWD." }; Receive-Job -AutoRemove -Wait $jb
Hi from C:\Program Files\PowerShell\6.0.0-beta.4

Environment data

PowerShell Core v6.0.0-beta.4 on macOS 10.12.5
PowerShell Core v6.0.0-beta.4 on Ubuntu 16.04.2 LTS
PowerShell Core v6.0.0-beta.4 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.413 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)

[mklement0]

I consider -InitializationScript {Set-Location $using:PWD} awkward too.

Having a -WorkingDirectory is a matter of convenience first and foremost, and it also provides symmetry with Start-Process.

You’re running a script block / script somewhere, and it’s helpful to have a simple way to control that somewhere.

This is especially true with the current behavior, where you - invisibly - run in a location other than the current one (unlike when you use the new & operator on Unix - a regrettable discrepancy - see #4267).

As an aside, re implementation detail: Understanding the underpinnings of jobs is important, because users need to be aware that a separate process and remoting are involved to understand that deserialized objects are returned.

[KirkMunro]

@davinci26 I wouldn’t inject anything into the script block. That could result in some surprises if/when you debug a job (i.e. you should only see your job script when you debug a job, not extra stuff that your job script didn’t include). Instead I’d just set the location when the runspace associated with the job is created, before the script block is run inside of it.