Using a local shell on a remote machine
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I use zsh
with a bunch of customizations on my local machine. I recently started using homemaker
to manage all my dotfiles in a git
repo on a private server. However, it always strikes me as awkward that when I ssh
in to a remote server, I either need to put up with the local config, or waste time cloning a private git
repo and running scripts. It also strikes me as unprofessional for me to download a bunch of personal files to a server I'm maintaining, especially if I'm not the main administrator.
It seems like there must be a better way. Is there some sort of system that allows me to run my carefully configured local shell, but all of the actual actions (file I/O, running commands/commadn stdio, etc) run over some sort of ssh
-based interface? I'm imagining some sort of super-minimal non-human-friendly shell (for the sake of this question, let's call it syssh
) on the server that just exposes all the system calls a modern shell could use, and on the client a modified shell that reads local configs but sends syssh
commands to the remote system.
This way, the server doesn't have to care about my preferred shell, promptline theme, color preferences, terminal capabilities, fonts (for powerline etc), tab completion preferences, etc. Also, network latency would not slow down my typing since readline()
is happening locally; the only thing that would lag would be the results of commands (and tab completion stuff, etc). I know mosh
addresses this problem through a bunch of heuristics and assumptions about how a shell would behave, but it seems a bit hackish.
The way it seems to me, running a shell over ssh
is like using a web app where every single button is a link or form submit button, mosh
is the same app with some caching and a differential compression scheme, and what I'm proposing would be like a modern webapp with Javascript manipulating the display and AJAX calls to get/post data when needed.
Does such a thing exist, and if not, why? Are there any known development efforts towards such a thing?
linux shell ssh
 |Â
show 1 more comment
up vote
6
down vote
favorite
I use zsh
with a bunch of customizations on my local machine. I recently started using homemaker
to manage all my dotfiles in a git
repo on a private server. However, it always strikes me as awkward that when I ssh
in to a remote server, I either need to put up with the local config, or waste time cloning a private git
repo and running scripts. It also strikes me as unprofessional for me to download a bunch of personal files to a server I'm maintaining, especially if I'm not the main administrator.
It seems like there must be a better way. Is there some sort of system that allows me to run my carefully configured local shell, but all of the actual actions (file I/O, running commands/commadn stdio, etc) run over some sort of ssh
-based interface? I'm imagining some sort of super-minimal non-human-friendly shell (for the sake of this question, let's call it syssh
) on the server that just exposes all the system calls a modern shell could use, and on the client a modified shell that reads local configs but sends syssh
commands to the remote system.
This way, the server doesn't have to care about my preferred shell, promptline theme, color preferences, terminal capabilities, fonts (for powerline etc), tab completion preferences, etc. Also, network latency would not slow down my typing since readline()
is happening locally; the only thing that would lag would be the results of commands (and tab completion stuff, etc). I know mosh
addresses this problem through a bunch of heuristics and assumptions about how a shell would behave, but it seems a bit hackish.
The way it seems to me, running a shell over ssh
is like using a web app where every single button is a link or form submit button, mosh
is the same app with some caching and a differential compression scheme, and what I'm proposing would be like a modern webapp with Javascript manipulating the display and AJAX calls to get/post data when needed.
Does such a thing exist, and if not, why? Are there any known development efforts towards such a thing?
linux shell ssh
It's not clear what this idea would look like, exactly. If your shell's syscalls are intercepted and executed remotely then your shell won't find its libraries, configuration files, and support files, because they don't exist on the remote system. Anyway, it seems kind of equivalent to copying the binary over there and running it there. All of this is assuming the two operating systems are compatible, of course, which might not be the case.
â Celada
Nov 3 '16 at 21:42
3
If you want your local applications to access data on the remote system's file system like in your editor case, you can use sshfs. If not, you may want to give a few more examples.
â Stéphane Chazelas
Nov 3 '16 at 21:44
1
I guess it would need to be a bit deeper than just intercepting syscalls. The more I think about it the less trivial it seems :( I guess I just think it would be nice if there was a common interface for shells to interact with a remote system; it seems messy to run a potentially heavy shell on a remote, possibly embedded machine. Like, why should my webserver care about tab-completion rules for systemd unit files, or prompt color schemes? Or why should my server need to somehow figure out if clients have the powerline fonts installed? That seems like code that should run on the client.
â dn3s
Nov 3 '16 at 23:02
@Celada edited to remove reference to syscall interception. Thanks!
â dn3s
Nov 3 '16 at 23:06
edited to clarify more
â dn3s
Nov 3 '16 at 23:18
 |Â
show 1 more comment
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I use zsh
with a bunch of customizations on my local machine. I recently started using homemaker
to manage all my dotfiles in a git
repo on a private server. However, it always strikes me as awkward that when I ssh
in to a remote server, I either need to put up with the local config, or waste time cloning a private git
repo and running scripts. It also strikes me as unprofessional for me to download a bunch of personal files to a server I'm maintaining, especially if I'm not the main administrator.
It seems like there must be a better way. Is there some sort of system that allows me to run my carefully configured local shell, but all of the actual actions (file I/O, running commands/commadn stdio, etc) run over some sort of ssh
-based interface? I'm imagining some sort of super-minimal non-human-friendly shell (for the sake of this question, let's call it syssh
) on the server that just exposes all the system calls a modern shell could use, and on the client a modified shell that reads local configs but sends syssh
commands to the remote system.
This way, the server doesn't have to care about my preferred shell, promptline theme, color preferences, terminal capabilities, fonts (for powerline etc), tab completion preferences, etc. Also, network latency would not slow down my typing since readline()
is happening locally; the only thing that would lag would be the results of commands (and tab completion stuff, etc). I know mosh
addresses this problem through a bunch of heuristics and assumptions about how a shell would behave, but it seems a bit hackish.
The way it seems to me, running a shell over ssh
is like using a web app where every single button is a link or form submit button, mosh
is the same app with some caching and a differential compression scheme, and what I'm proposing would be like a modern webapp with Javascript manipulating the display and AJAX calls to get/post data when needed.
Does such a thing exist, and if not, why? Are there any known development efforts towards such a thing?
linux shell ssh
I use zsh
with a bunch of customizations on my local machine. I recently started using homemaker
to manage all my dotfiles in a git
repo on a private server. However, it always strikes me as awkward that when I ssh
in to a remote server, I either need to put up with the local config, or waste time cloning a private git
repo and running scripts. It also strikes me as unprofessional for me to download a bunch of personal files to a server I'm maintaining, especially if I'm not the main administrator.
It seems like there must be a better way. Is there some sort of system that allows me to run my carefully configured local shell, but all of the actual actions (file I/O, running commands/commadn stdio, etc) run over some sort of ssh
-based interface? I'm imagining some sort of super-minimal non-human-friendly shell (for the sake of this question, let's call it syssh
) on the server that just exposes all the system calls a modern shell could use, and on the client a modified shell that reads local configs but sends syssh
commands to the remote system.
This way, the server doesn't have to care about my preferred shell, promptline theme, color preferences, terminal capabilities, fonts (for powerline etc), tab completion preferences, etc. Also, network latency would not slow down my typing since readline()
is happening locally; the only thing that would lag would be the results of commands (and tab completion stuff, etc). I know mosh
addresses this problem through a bunch of heuristics and assumptions about how a shell would behave, but it seems a bit hackish.
The way it seems to me, running a shell over ssh
is like using a web app where every single button is a link or form submit button, mosh
is the same app with some caching and a differential compression scheme, and what I'm proposing would be like a modern webapp with Javascript manipulating the display and AJAX calls to get/post data when needed.
Does such a thing exist, and if not, why? Are there any known development efforts towards such a thing?
linux shell ssh
linux shell ssh
edited Nov 3 '16 at 23:18
asked Nov 3 '16 at 20:56
dn3s
1513
1513
It's not clear what this idea would look like, exactly. If your shell's syscalls are intercepted and executed remotely then your shell won't find its libraries, configuration files, and support files, because they don't exist on the remote system. Anyway, it seems kind of equivalent to copying the binary over there and running it there. All of this is assuming the two operating systems are compatible, of course, which might not be the case.
â Celada
Nov 3 '16 at 21:42
3
If you want your local applications to access data on the remote system's file system like in your editor case, you can use sshfs. If not, you may want to give a few more examples.
â Stéphane Chazelas
Nov 3 '16 at 21:44
1
I guess it would need to be a bit deeper than just intercepting syscalls. The more I think about it the less trivial it seems :( I guess I just think it would be nice if there was a common interface for shells to interact with a remote system; it seems messy to run a potentially heavy shell on a remote, possibly embedded machine. Like, why should my webserver care about tab-completion rules for systemd unit files, or prompt color schemes? Or why should my server need to somehow figure out if clients have the powerline fonts installed? That seems like code that should run on the client.
â dn3s
Nov 3 '16 at 23:02
@Celada edited to remove reference to syscall interception. Thanks!
â dn3s
Nov 3 '16 at 23:06
edited to clarify more
â dn3s
Nov 3 '16 at 23:18
 |Â
show 1 more comment
It's not clear what this idea would look like, exactly. If your shell's syscalls are intercepted and executed remotely then your shell won't find its libraries, configuration files, and support files, because they don't exist on the remote system. Anyway, it seems kind of equivalent to copying the binary over there and running it there. All of this is assuming the two operating systems are compatible, of course, which might not be the case.
â Celada
Nov 3 '16 at 21:42
3
If you want your local applications to access data on the remote system's file system like in your editor case, you can use sshfs. If not, you may want to give a few more examples.
â Stéphane Chazelas
Nov 3 '16 at 21:44
1
I guess it would need to be a bit deeper than just intercepting syscalls. The more I think about it the less trivial it seems :( I guess I just think it would be nice if there was a common interface for shells to interact with a remote system; it seems messy to run a potentially heavy shell on a remote, possibly embedded machine. Like, why should my webserver care about tab-completion rules for systemd unit files, or prompt color schemes? Or why should my server need to somehow figure out if clients have the powerline fonts installed? That seems like code that should run on the client.
â dn3s
Nov 3 '16 at 23:02
@Celada edited to remove reference to syscall interception. Thanks!
â dn3s
Nov 3 '16 at 23:06
edited to clarify more
â dn3s
Nov 3 '16 at 23:18
It's not clear what this idea would look like, exactly. If your shell's syscalls are intercepted and executed remotely then your shell won't find its libraries, configuration files, and support files, because they don't exist on the remote system. Anyway, it seems kind of equivalent to copying the binary over there and running it there. All of this is assuming the two operating systems are compatible, of course, which might not be the case.
â Celada
Nov 3 '16 at 21:42
It's not clear what this idea would look like, exactly. If your shell's syscalls are intercepted and executed remotely then your shell won't find its libraries, configuration files, and support files, because they don't exist on the remote system. Anyway, it seems kind of equivalent to copying the binary over there and running it there. All of this is assuming the two operating systems are compatible, of course, which might not be the case.
â Celada
Nov 3 '16 at 21:42
3
3
If you want your local applications to access data on the remote system's file system like in your editor case, you can use sshfs. If not, you may want to give a few more examples.
â Stéphane Chazelas
Nov 3 '16 at 21:44
If you want your local applications to access data on the remote system's file system like in your editor case, you can use sshfs. If not, you may want to give a few more examples.
â Stéphane Chazelas
Nov 3 '16 at 21:44
1
1
I guess it would need to be a bit deeper than just intercepting syscalls. The more I think about it the less trivial it seems :( I guess I just think it would be nice if there was a common interface for shells to interact with a remote system; it seems messy to run a potentially heavy shell on a remote, possibly embedded machine. Like, why should my webserver care about tab-completion rules for systemd unit files, or prompt color schemes? Or why should my server need to somehow figure out if clients have the powerline fonts installed? That seems like code that should run on the client.
â dn3s
Nov 3 '16 at 23:02
I guess it would need to be a bit deeper than just intercepting syscalls. The more I think about it the less trivial it seems :( I guess I just think it would be nice if there was a common interface for shells to interact with a remote system; it seems messy to run a potentially heavy shell on a remote, possibly embedded machine. Like, why should my webserver care about tab-completion rules for systemd unit files, or prompt color schemes? Or why should my server need to somehow figure out if clients have the powerline fonts installed? That seems like code that should run on the client.
â dn3s
Nov 3 '16 at 23:02
@Celada edited to remove reference to syscall interception. Thanks!
â dn3s
Nov 3 '16 at 23:06
@Celada edited to remove reference to syscall interception. Thanks!
â dn3s
Nov 3 '16 at 23:06
edited to clarify more
â dn3s
Nov 3 '16 at 23:18
edited to clarify more
â dn3s
Nov 3 '16 at 23:18
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
1
down vote
It sounds like what you want is Microsoft's Web Services for Management
which is the basis for powershell
remoting. Powershell for Linux exists and is MIT licensed so it should in theory be possible to extract the necessary code and turn it into a patch for zsh
. Of course not everyone will have powershell installed but the not everybody has zsh installed.
In short what you want exists but not (yet) for zsh
.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
It sounds like what you want is Microsoft's Web Services for Management
which is the basis for powershell
remoting. Powershell for Linux exists and is MIT licensed so it should in theory be possible to extract the necessary code and turn it into a patch for zsh
. Of course not everyone will have powershell installed but the not everybody has zsh installed.
In short what you want exists but not (yet) for zsh
.
add a comment |Â
up vote
1
down vote
It sounds like what you want is Microsoft's Web Services for Management
which is the basis for powershell
remoting. Powershell for Linux exists and is MIT licensed so it should in theory be possible to extract the necessary code and turn it into a patch for zsh
. Of course not everyone will have powershell installed but the not everybody has zsh installed.
In short what you want exists but not (yet) for zsh
.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
It sounds like what you want is Microsoft's Web Services for Management
which is the basis for powershell
remoting. Powershell for Linux exists and is MIT licensed so it should in theory be possible to extract the necessary code and turn it into a patch for zsh
. Of course not everyone will have powershell installed but the not everybody has zsh installed.
In short what you want exists but not (yet) for zsh
.
It sounds like what you want is Microsoft's Web Services for Management
which is the basis for powershell
remoting. Powershell for Linux exists and is MIT licensed so it should in theory be possible to extract the necessary code and turn it into a patch for zsh
. Of course not everyone will have powershell installed but the not everybody has zsh installed.
In short what you want exists but not (yet) for zsh
.
answered Sep 3 at 8:09
William Hay
21317
21317
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f320902%2fusing-a-local-shell-on-a-remote-machine%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
It's not clear what this idea would look like, exactly. If your shell's syscalls are intercepted and executed remotely then your shell won't find its libraries, configuration files, and support files, because they don't exist on the remote system. Anyway, it seems kind of equivalent to copying the binary over there and running it there. All of this is assuming the two operating systems are compatible, of course, which might not be the case.
â Celada
Nov 3 '16 at 21:42
3
If you want your local applications to access data on the remote system's file system like in your editor case, you can use sshfs. If not, you may want to give a few more examples.
â Stéphane Chazelas
Nov 3 '16 at 21:44
1
I guess it would need to be a bit deeper than just intercepting syscalls. The more I think about it the less trivial it seems :( I guess I just think it would be nice if there was a common interface for shells to interact with a remote system; it seems messy to run a potentially heavy shell on a remote, possibly embedded machine. Like, why should my webserver care about tab-completion rules for systemd unit files, or prompt color schemes? Or why should my server need to somehow figure out if clients have the powerline fonts installed? That seems like code that should run on the client.
â dn3s
Nov 3 '16 at 23:02
@Celada edited to remove reference to syscall interception. Thanks!
â dn3s
Nov 3 '16 at 23:06
edited to clarify more
â dn3s
Nov 3 '16 at 23:18