Needs to show an error (rather than just a blank tab) if a shell is missing

[mikemaccana]

New box, installed 1903 and Windows Terminal.

Starting a new terminal shows no UI:

It looks like this is because C:\\Program Files\\PowerShell\\6\\pwsh.exe is missing. Terminal should show a message like:

Couldn't start profile 'powershell'
The file C:\\Program Files\\PowerShell\\6\\pwsh.exe is missing.

[zadjii-msft]

This is something we can totally do. We'd probably want to somehow have the TermControl surface this error to the App, and have the app display the exception using it's message box. When the App catches the exception, it should probably not open the tab/pane for that control it's trying to create.

Part of the trick here will be doing this before adding the control to the UI. We'd probably want to have a TermControl::ValidateSettings method, that throws/returns an HRESULT if it fails to validate. That way we could validate both the commandline, and other things, like the font. We'd construct the TermControl using the TerminalSettings, then ask the control to validate those settings. If the control returns an error, then we'll just not create the tab/pane, and display the error dialog.

[DHowett-MSFT]

We can't totally validate a commandline without trying to spawn it. Perhaps we can surface an error up through ConhostConnection? Eventually ConptyConnection will know better because it gets to CreateProcess the shell directly, and can more directly signal failure there.

[zadjii-msft]

We could certainly do that. I was more imagining that TermControl would ask the connection to validate it's own settings, and as a basic sanity check, ensure that the file exists.

Oh you're right though, for something like foo.exe --bar, we can't get at just the foo.exe part.

That's extra tricky.

Maybe we'd have to start the connection before TermControl::_Initialize, and just do nothing with i/o from the connection until the control is actually initialized.

[DHowett-MSFT]

I'm of two minds here. I think we should detect failures early where we can, but I also think that this is a perfectly acceptable (good! maybe better!) experience:

because this dovetails nicely with:

closeOnExit = false

[binarycrusader]

I'm of two minds here. I think we should detect failures early where we can, but I also think that this is a perfectly acceptable (good! maybe better!) experience:

The error code could also be translated to the human-friendly name for the user if the error code can be mapped. Also, in addition to that text, it might be useful to having diagnostics tailored to the specific error code. For example, if CreateProcess fails, and a simple existence / permissions check fails for the executable, a much better diagnostic message could be provided to the user.

For example, if spawning fails and the process discovers that wsl.exe can't be found, it could point the user at the Store app and suggest it doesn't appear to be installed, but they can install a Linux distribution from the Store?

The error code alone though I personally think is the right start, but some really great stuff could be done on top of that.

[miniksa]

#1348 is relevant here

[miniksa]

OK so this is the way to fix the pwsh is missing thing that a lot of people have been hitting. Some sort of indication that it failed. Or a #1348 fallback to a different default. Or something.

But both #2091 from @mcpiroman and #2039 from @DHowett-MSFT show that this is being handled by others and will resolve itself when those get resolved. So I'm not going to take and pursue this further right now.

[zadjii-msft]

Hey @DHowett-MSFT did the whole graceful exit thing fix this?

[DHowett-MSFT]

Yep, this was fixed in #3623

[DHowett-MSFT]

Thanks for the find!

[ghost]

🎉This issue was addressed in #3623, which has now been successfully released as Windows Terminal Preview v0.8.10091.0.:tada:

Handy links:

• Release Notes
• Store Download