CLRCLI over Win32 OpenSSH

[Fitzroy87]

I was curious to see whether this library would work over SSH...

I connected from a Windows 7 machine using the Win32 OpenSSH client to another Windows 7 machine (running the Win32 OpenSSH server) and launched the the sample script from this blog post. It worked, however the box drawing characters did not render correctly:

[PhonicUK]

What happens if you use Putty as the SSH client instead?

[Fitzroy87]

Using PuTTY as the client didn't make any difference. The characters that fail to render correctly are represented in exactly the same way as the OpenSSH client.

I tried changing the console's active code page using chcp (whilst using PuTTY and the Win32 OpenSSH client) - it was possible to get a tad closer to displaying actual line/box drawing characters but not possible to replicate the characters as they are intended to be displayed.

The problem appears to be with the Win32 OpenSSH server. I have logged this as an issue: PowerShell/Win32-OpenSSH#352

As I have yet to receive any feedback, I don't know if:
A) There is already a solution to this problem that can be coded for in your project.
Or
B) It's a bug/limitation for which there is currently no solution.

It should be noted that at the time of writing, the Win32 OpenSSH project is still very much under development...

Your project has sparked some discussion in PowerShell communities, so hopefully some others will have something to contribute...

[PhonicUK]

What's the default code page? CP437 does have the requisite lineart characters.

[Fitzroy87]

The default is 850. Changing to 437 doesn't rectify the issue.

[PhonicUK]

What happens if you put this in your application before root.run?

Console.OutputEncoding = ASCIIEncoding.GetEncoding(850);

[Fitzroy87]

This is a PowerShell script, not C#. So I'd say that setting the console's active code page using chcp is equivalent to 'Console.OutputEncoding = ASCIIEncoding...'

[PhonicUK]

I suspect what's going on is there's a mismatch between the consoles code page and the output encoding being sent to the console. That's why I'd want to try explicitly setting the output encoding at the application level to match what the console is.

[Fitzroy87]

I'm going to have a read of this MSDN article tomorrow: https://blogs.msdn.microsoft.com/powershell/2006/12/11/outputencoding-to-the-rescue/

I should be able to modify the examples to implement your suggestion. Will report back with my findings...

[Fitzroy87]

I've ported your suggestion to PowerShell and incorporated it into my script:

[Console]::OutputEncoding = [System.Text.ASCIIEncoding]::GetEncoding(850)

However I'm afraid it hasn't made any difference...

[Fitzroy87]

I conducted my original tests using Win32 OpenSSH version 0.0.1.0 on both the client and the server. Since then, there have been two subsequent releases, version 0.0.2.0 and 0.0.3.0.

I have updated both the client (on the machine from which I am connecting) and server (on the machine to which I am connecting) from Win32 OpenSSH version 0.0.1.0 to 0.0.3.0.

Under version 0.0.3.0, the lineart characters are displayed in a far more pleasing way. It's not an exact facsimilie of what's displayed when running the script locally - but it's a vast improvement over version 0.0.1.0:

NB: Using the Win32 OpenSSH client results in the lineart characters at the bottom of the window to be displayed oddly. This does not happen if using PuTTY as the client.

[PhonicUK]

Has anyone tried using powershell remoting to see how that behaves?

[Fitzroy87]

It wouldn't work because PowerShell remoting doesn't support interactive console activity. Simply put, it just executes commands and displays the results or deserializes them as objects.