port vmserial-connect to powershell

[b-]

in case you want to enter the serial console on a Hyper-V server without WSL

still requires socat, obviously, but installing it on Windows is a little more complicated than using your package manager. I've tested with the one from unix-utils and it works great, but if I use the socat from msys2 my terminal sends extra return characters and I'm not sure why.

I would prefer an easier way to put socat in, perhaps a statically-compiled one (or a wild enough wish could even be just to implement the fancy PTY stuff necessary in npiperelay itself?)

[albertony]

Hi.

Sorry for responding so late. Didn't notice the PR until now - this is the first ever PR from anyone other than myself, and my trusty old new friend dependabot... But thank you! :)

I have not touched into many of the use cases, and the scripts and docs for these are mostly inherited from the upstream project. So regarding your change; Does it change how you use it, e.g. how you execute the script? Is the documentation at https://github.com/albertony/npiperelay#connecting-to-a-hyper-v-linux-vms-serial-console still valid? Is there any reason we should keep the existing version and add yours as an alternative, and document it as such, instead?

[b-]

Hi! I pulled on your fork because the upstream doesn't seem to be active anymore, and yours seems to be the most active fork of it on GitHub. Maybe this is a little presumptuous of me, but I think that kind of means you're upstream, now!

I should've updated documentation via my PR — I can probably do that. This has the same syntax, but the difference is that it's a PowerShell script, meant to run natively on a Hyper-V host machine. The one from upstream is a bash script that appears to be intended to be run from within Windows Subsystem for Linux.

Being able to connect to your serial console from WSL is kind of cool, I guess? But it's also pretty weird to me, because I can't really imagine a scenario where I would have WSL installed on a production Hyper-V host.

In other words, the upstream script depends on WSL (and a socat package) vs this one requiring nothing but PowerShell...and a copy of socat for Windows.

I'm a little hesitant to say that this should replace the upstream bash script, though, because it seems to me that socat for Windows has slightly different behavior with regards to PTYs depending on the build and/or compiler settings.

I'm really not sure why, but I mentioned somewhere in my PR about how I couldn't build or install a "good" socat using mingw (which was about where I gave up there). The one from mingw had some weird issue that I don't remember the specifics of except that it didn't work as I expected and kind of mangled some things. Might have been something to do with newline processing. The terminal output was getting mangled, anyway…

On the other hand, a build of socat.exe that I bravely tried from a random "posix utils for Windows" page on SourceForge from like 5 years ago does work, but I have no idea how I'd even begin to figure out what the difference is or how I might be able to reproduce this with a more modern socat that I feel a little more comfortable about the source of.

I'm just sort of assuming the socat.exe that works for me has some specific patches, and I'd rather either have it work with upstream socat e.g., from mingw, or at least be able to easily compile our own socat to bundle with this.

So to be clear, my PowerShell script does work (and well enough that I used it in production at least on my home router for a few months), but given the "weird" dependency of a random build of socat I don't wanna say it should replace the bash script (even as what's mentioned in the docs).

Maybe my PowerShell script should be added to the docs as well, just with a bit of a caveat emptor with regards to the socat.exe. We could even put the .exe/its source/its license into the repository, too.

What do you think?

[albertony]

Thank you for the explanation. I understand, and do agree with what you say.

Maybe my PowerShell script should be added to the docs as well, just with a bit of a caveat emptor with regards to the socat.exe.

I think that's a good idea, and one reason is this - chances are it might be useful for others as well:

my PowerShell script does work (and well enough that I used it in production at least on my home router for a few months)

So, if you are willing to change the PR to make your script an additional alternative instead, keeping the existing bash script, and also add a section in readme for it, then I think its worth merging for sure.

We could even put the .exe/its source/its license into the repository, too.

I don't want the .exe in. Source could be an option, but I would rather consider making that a separate repo and refer to it. I'm working on a static linux build of socat for some of my own use cases with npiperelay, by the way. Considering setting up a repo with just build scripts, that fetches external source code and then builds and publishes binaries for easy copy-install. Haven't decided where to put it yet, part of this or some other project, or as a separate project, but if we had the necessary steps to build a working version for Windows as well these could be combined in a dedicated "socat-binaries" repo...

[b-]

So, if you are willing to change the PR to make your script an additional alternative instead, keeping the existing bash script, and also add a section in readme for it, then I think its worth merging for sure.

Awesome, I'll get that done

I don't want the .exe in. Source could be an option, but I would rather consider making that a separate repo and refer to it. I'm working on a static linux build of socat for some of my own use cases with npiperelay, by the way. Considering setting up a repo with just build scripts, that fetches external source code and then builds and publishes binaries for easy copy-install. Haven't decided where to put it yet, part of this or some other project, or as a separate project, but if we had the necessary steps to build a working version for Windows as well these could be combined in a dedicated "socat-binaries" repo...

I agree, I don't really like storing binaries directly in git repositories. One repository I contribute to is, like, 30 GB, and I'm sure that them storing binaries in there is part of the problem…

I didn't want to ask you to work on a socat build, but I was actually thinking that would be pretty ideal, anyway… it would probably make it a lot easier to find and fix whatever was causing the text processing issue I was having, anyway!

So I'll update the readme to mention the PowerShell vmconnect script, with a link to the socat on sourceforge (and a blurb about the reasoning), and we can change that link to a socat-build repo eventually, too. Awesome! Thanks!