You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 17, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 17, 2021. It is now read-only.
Well what if a user wants to pass advanced ssh flags to the server? Like
proxy back another port at the same time if they are developing a project
that uses web technologies.
And for rsync, that looks interesting, if you want to make a PR, feel free.
Why run three commands instead of one?
The logic you have just isn't there,
And having ssh flags make it easier to add ssh features as we can just used
those flags.
Or people can use the flags to do more things than what sshcode has built
in.
Interesting difference in perspective; I personally strive for the model of "do one thing well and leave other out of scope functionality up to other applications"; the idea of using sshcode for anything other than starting my code-server and vscode connection never crossed my mind.
Counterpoint; what if all I want is to start code-server and vscode from a minimal environment, first I must install ssh just so os.Exec can call the binary instead of the functionality being compiled into the application itself; this seems more cumbersome than running other entirely not related functions in a separate command.
Hmm... Good counterpoint.
Maybe check if ssh binary exists in PATH, if not, then fall back to the ssh
library in golang and notify that certain capabilities will not function as
intended such as rsync?
On Tue, Dec 31, 2019, 9:31 AM Nathan Bass ***@***.***> wrote:
Interesting difference in perspective; I personally strive for the model
of "do one thing well and leave other out of scope functionality up to
other applications"; the idea of using sshcode for anything other than
starting my code-server and vscode connection never crossed my mind.
Counterpoint; what if *all* I want is to start code-server and vscode
from a minimal environment, first I must install ssh just so os.Exec can
call the binary instead of the functionality being compiled into the
application itself; this seems more cumbersome than running other *entirely
not related* functions in a separate command.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#160>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPQOXWGV3OHYSGVHNZGTZ3Q3N6XVANCNFSM4KAAY6RA>
.
Activity
Merith-TK commentedon Dec 27, 2019
IngCr3at1on commentedon Dec 30, 2019
I was also wondering, but to that end, I don't quite understand the following.
specifically what "flag support"?
As for rsync I wonder if https://github.com/mutagen-io/mutagen/tree/master/pkg/synchronization/rsync should be considered instead of requiring rsync itself to be installed (might be worth a separate issue to discuss rsync as it's own topic).
Merith-TK commentedon Dec 31, 2019
GrimTheReaper commentedon Dec 31, 2019
If they want to open up a port, why not open up another ssh connection, or use some other tool?
Merith-TK commentedon Dec 31, 2019
IngCr3at1on commentedon Dec 31, 2019
Interesting difference in perspective; I personally strive for the model of "do one thing well and leave other out of scope functionality up to other applications"; the idea of using sshcode for anything other than starting my code-server and vscode connection never crossed my mind.
Counterpoint; what if all I want is to start code-server and vscode from a minimal environment, first I must install ssh just so os.Exec can call the binary instead of the functionality being compiled into the application itself; this seems more cumbersome than running other entirely not related functions in a separate command.
Merith-TK commentedon Dec 31, 2019