Fail gracefully for impossible hosts about terminal.gui HOT 4 OPEN

Here are some things that are true in a Remoting session:

• Console.IsInputRedirected
• Console.IsOutputRedirected
• The PowerShell global session variable $PSSenderInfo is not null and is a dictionary
  • This one likely isn't accessible without referencing the PowerShell APIs because they're not environment variables - they're just ambient data in the PowerShell application itself, and aren't directly exposed to anything inside it as far as I know.

But...

The redirection alone is probably enough, at least with how Terminal.Gui currently works. Redirection of the in and out streams will break it, so a simple check against those first two boolean properties before doing anything else and throwing a meaningful exception or something is probably sufficient.

Any thoughts?

from terminal.gui.

And just for the record, I don't think TG breaking on redirection is a good thing to be a permanent limitation. But I suspect it's a bit too much for V2 to make it work with that, so that seems like an acceptable means of detecting an unsupported environment and terminating, right now.

from terminal.gui.

I played around with some code for a bit since I got annoyingly fixated on this (done now though)...

The environment variables that are set make it almost look like a normal interactive session, aside from missing $TERM, $COLUMNS, and $LINES. Those are simply not even defined, by default, at least in a PS Remoting session from my Windows 11 PC with PS 7.5 preview 3 remoting to an Ubuntu 24.04 system with the same version of PowerShell. It even shows as being on top of bash, in this particular environment, which was a semi-surprising thing since I figured the login shell for the user would have been bypassed. But it appears the user's default shell is being loaded. I changed the default shell for a user to sh and opened a new session to check that hypothesis, which was confirmed.

I don't know why the behavior when you've entered the session isn't to re-redirect the stdin and stdout streams to the active shell, but it isn't, so PS Remoting is currently just not compatible with a TG application.

There are a few other environment variables that are not there, so it's clearly not loading the shell with the logged in user's profile (I've got a .bashrc that sets a bunch of stuff up and it wasn't there in the bash case), but they're not helpful or in any significant way an actual indicator of what the environment is, anyway, as far as I can see without spending more time on it that I don't want to waste.

I suppose another option for validating the environment - which would need to be conditionally skipped if AoT compiled, because it isn't trim friendly - would be to attempt to load the System.Management.Automation library into the AppDomain to make the check, so that it could be used without having a hard compile-time dependency. Inability to load the assembly would mean you're not in PowerShell (probably), and if you can load it you can access the PS session variables through that API... But that's gross IMO, and the checks for redirection seem good enough for the time being.

Besides, it's likely to be a corner case anyway. Even if usage does explode after V2 release and people start running into the problem, it can simply be addressed by documenting it as an unsupported environment until or unless a driver that works with it is ever created by some ambitious individual. 🤷‍♂️

And if you have the ability to use PSRemoting over SSH, you already apparently have SSH, so you can just connect in a normal session and move on with life.

from terminal.gui.

Huh. Maybe it's lying actually...

Process list shows the pwsh-preview process directly owned by sshd, so... 🤷‍♂️

Back to work on important stuff now...

from terminal.gui.