Windows support on the client-side?

[Sz.]

I've seen #94, but from a generic user's perspective, and after just reading the README, and being vaguely familiar with the concept, I can see no obvious reason why the Go client-side should be Linux-only.

Adding Windows support seems a) relatively low-cost, and b) would be a huge benefit all alone, even regardless of any specific compiler toolkit support etc.

(Note: Linux-only server support is perfectly fine, a Linux dev. server + Win client is a common use case.)

So, basically out of curiosity: what's the actual roadblock that prevents it from "just working" on a Windows client? Thanks!

[Merith]

The main roadblock, is how the program is currently executing `ssh`, it is using the linux/Unix program `sh` which does not exist in the windows path, so right now it can only run under `git for Windows`, `msys2`, or other cygwin based environments with ssh on the path Go ahead and try and compile my fork on windows, the issue is that even when I DIRECTLY POINT IT TO THE FILE PATH TO `ssh.exe` it says it does not exist.

…

On Mon, Aug 5, 2019, 9:17 AM Szabi ***@***.***> wrote: I've seen #94 <#94>, but from a generic user's perspective, and after just reading the README, and being vaguely familiar with the concept, I can see no obvious reason why the Go client-side should be Linux-only. Adding Windows support seems a) relatively low-cost, and b) would be a huge benefit all alone, even regardless of any specific compiler toolkit etc. (Note: Linux-only server support is perfectly fine, a Linux dev. server + Win client is a common use case.)_ So, basically out of curiosity: what's the actual roadblock that prevents it from "just working" on a Windows client? Thanks! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#130>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPQOXRHK6KXPWY7KEAF3FLQDBHC7ANCNFSM4IJM2DTA> .

[Merith]

#127 check out my PR for a more detailed list of issues I've noticed,

[Sz.]

Thanks, great news overall!
(Alas, I can only vaguely guess, what could be causing that exec problem, like missing DLLs, incorrect use of quotes, char encoding mismatch etc. etc.)

[Merith]

surprisingly, no.
ssh.exe is preinstalled and (i think) C:\Windows\System32\OpenSSH on windows 10 path by default,

The issue is that sshcode exec's the program on the CLIENT SIDE by using sh with some other flags, and even when i make it exec ssh.exe directly, it says it cannot find the program to launch.

So currently the only way to use sshcode on windows (any version) is via git4win, cygwin, or msys2.
(assuming your using a fork or have modified it enough to use chrome.exe (see some of my earliar commits)

[Merith]

welp
Mingw enviroments now work. assuming you have rsync installed.

[Merith]

Fork is mostly functional, good for everyday simple usage

[Merith]

#132
refer to this PR from now on.

Currently fighting a minor issue where windows send ~/ as a literal path, so it is the equivalent of '~'/