Re: Feature Request: Sync via `wsl --exec`

 (Sorry for sending it again. I've sent by an email address not belonging
to this ML)

I successfully confirmed that a wrapper around the wsl command to
parse the options of the ssh command enables ssh-free synchronization
with WSL's VM.

https://urldefense.com/v3/__https://gist.github.com/igrep/6f40888aab6268c1d4b4c89a27122627__;!!IBzWLUs!Va6LS1FesXo4ZRzzFYI6lULPStXaKLihOTbxgtK5HCmgzZRIIz3N9HH-WzLCyFUPu2h2eD2uYsLeYzODdNVpzzKbxi8acCRWLA$ 

Thanks again for the great advice!
And let me apologize for the first message.
I should have set the subject as, say, "Idea: Sync via `wsl --exec`".



2023年10月7日(土) 7:58 YAMAMOTO Yuji <[email protected]>:

> Thank you for detailed replies!
> I'll try the alternatives and they sound sufficient.
>
> 2023年10月7日(土) 2:04 Greg Troxel <[email protected]>:
>
>> YAMAMOTO Yuji <[email protected]> writes:
>>
>> > I'm recently using Unison to synchronize some of my source code
>> > from Linux on WSL to the C drive of the host Windows:
>> >
>> > Linux --- (unison -repeat watch) ---> Windows
>>
>> unclear which system you are running unison on.
>>
>> > Currently I have to install openssh-server and my public key on
>> > Linux only for Unison, which is a little cumbersome.
>>
>> It's really surprising that's the only reason (how do you do backups?),
>> but your world is what it is!
>>
>> > Now, I want to propose adding a new feature that enables unison
>> > to synchronize with the WSL VM via the `wsl --exec` command
>> > instead of `ssh`. `wsl --exec` can run arbitrary commands after
>> > automatically launching a WSL VM, which could make it feasible.
>>
>> I am not inclined to add Windows-specific features, as unison is already
>> much too complicated, and I view Windows as an edge case.  Each feature
>> helps some poeple, but complexity hurts everybody and it is not obvious
>> how to strike the balance.  But I wonder if this is really not "add
>> feature" but "configure which program is run to start unison on remote
>> host", and it's doable with something milder than "feature".  Or could
>> be done in such a way that other uses will work (other containers, and
>> situations I haven't thought of).
>>
>> Right now we have URI schemes, and ssh: is pretty top level.  On one
>> hand that's odd, but on the other ssh has become the sole method to
>> execute commands on remote systems.
>>
>> You could create a wrapper script ssh which instead does wsl --exec,
>> depending on hostname.  That is probably the easiest path to what you
>> want.
>>
>> Finally, you called this "feature request" which is fair, but largely if
>> you want a feature you will have to write the code.  It is good to talk
>> about it here because you may want to skip the effort if it's going to
>> be architecturally rejected -- although of course anyone is welcome to
>> make changes and share them.
>>
>>

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].