Terminal Preview returns ERROR_FILE_NOT_FOUND when launching relative path

[ChrisKnue-MSFT]

Windows Terminal version

1.18.1421.0

Windows build number

10.0.22631.0

Other Software

No response

Steps to reproduce

Attempt to launch a terminal from command line with a relative path for a file to launch. (ex: "wt .\test.ps1")

Expected Behavior

In 1.16.10262.0 this would launch the file

Actual Behavior

[error 2147942402 (0x80070002) when launching .\test.ps1]
is printed in the console.

[zadjii-msft]

Undoubtably, I broke this in #15280. Or at least, forgot about this scenario 🤦

[zadjii-msft]

Hmmmmmm. This is tricky. So we've got a virtual CWD now, and our real CWD is system32.

As an example, cd to d:\dev\tmp, and try to launch foo.exe. In this scenario:

• when we get to _evaluatePathForCwd in TerminalPage::_CreateConnectionFromSettings, we evaluate (_WindowProperties.VirtualWorkingDirectory(), path) == ("d:\dev\tmp", "") -> `"d:\dev\tmp"'. That's right.
• But the problem is that we don't CreateProcess then. We CreateProcess in ConptyConnection::Start, which straight up isn't till the TermControl is initialized with XAML.
• At that point, we CreateProcess("foo.exe",..... "d:\dev\tmp"). But that gives a ERROR_FILE_NOT_FOUND, cause there's no foo.exe in system32.

I wonder if there's a trivial flag to try to load the process from the startingDirectory. Or like, as a fail-safe, fall back to trying the startingDirectory, like, by appending the commandline to that? idk. needs more brainstorming.

[zadjii-msft]

But it's not just {{startingDirectory}}/{{commandline}}. It's more like the search path has to be {{terminal's vCWD when that connection was created}}/{{commandline}}.

Ew this is hard. Cause we don't know the application that we're calling CreateProcess on. We're just passing the whole commandline, and letting CreateProcess figure it out. We could theoretically, temporarily attempt to have the Terminal cd into the vCwd, and try again. That also feels hacky but hey, that's kinda this whole project

[ChrisKnue-MSFT]

@zadjii-msft We were trying some work arounds (absolute path) and it seems like environment variables are not being passed to the child wt process either. Is there already a bug about that?

[zadjii-msft]

Talked this over internally - The fix (as in #16028) for this bug is.... unbelievably gross, and probably even incorrect. This is just gonna have to remain a breaking change post-1.18. The workaround being to always pass absolute paths to the wt commandline (which will work on old versions as well as new).