`$PSScriptRoot` and `$PSCommandPath` are not populated with `Start-Job -FilePath <filepath>`

Steps to reproduce

script.ps1:

echo $PSCommandPath
echo $PSScriptRoot

Run this in terminal:

Start-Job -FilePath .\script.ps1 | Receive-Job -Wait

Expected behavior

<path-to-script.ps1>
<path-to-scrpt.ps1-dir>

Actual behavior

(2 empty lines)

Environment data

PSVersion                      7.2.0-preview.3
PSEdition                      Core
GitCommitId                    7.2.0-preview.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[mklement0]

The explanation for the current behavior (which is definitely debatable) is implied by this line from the docs:

When you use this parameter, PowerShell converts the contents of the specified script file to a script block and runs the script block as a background job.

That is, the background job doesn’t execute the script file given, but its contents, as a script block - and such a script block has no information about where it ultimately came from.

While this behavior makes perfect sense in the context of remoting (with Invoke-Command -ComputerName $someComputer -FilePath ...), it arguably makes better sense to let a background job - which by definition runs on the same machine and can therefore access the specified file - execute the script file directly, so as not to lose invocation context.

[mklement0]

I don’t think security concerns are in the picture here, and my guess is that this was done more for the convenience of sharing an implementation with / behavioral symmetry with Invoke-Command -FilePath

That said, @MatejKafka, the problem is easily worked around by using a script block instead:

Start-Job { .\script.ps1 } | Receive-Job -Wait

Note that in Windows PowerShell this won’t necessarily work, because background jobs there don’t inherit the caller’s location, but in PowerShell Core that isn’t a problem anymore.