3 ms·

Just need to wait for a shell with native support for ssh

by dan-robertson 6y ago

gumby 6y ago
What would that look like? I’ve never felt constrained by just calling ssh.
- dan-robertson 6y ago
  1. When you ssh you get to continue with the benefits and syntax of your current shell. The closest I know to this is eshell which gets some access to remote hosts through tramp rather than ssh. 2. There’s a small family of commands that take commands as arguments, eg env, xargs, parallel, find, ssh. Maybe they should get special support and the shell should allow you to write subshells to be passed to these commands in some first-class way, similar to the way bash magically converts <(...) into a special file name arg with a process running redirected to that file
  - gumby 6y ago
    Ah, I get it. Right now I just run commands remotely by prefixing ssh (actually I have aliases for the commonly connected machines). So it's ls for local list and ssh remote ls for remote's ls (actually I type remote-name ls ). So things like $! or ^ work as expected since they operate normally, but some quoting is indeed required (e.g. I usually want a pipeline to run entirely, or mostly, remotely). But as each invocation invokes a fresh shell the remote connection is stateless. It would be nice if the shell could track things like remote cd and prefix subsequent commands with `cd`. This is hard to get right; there are so many ways to cd or pushd/popd (especially in `()` sub shells or with !:xx kinds of shortcuts) that they are hard to find. Emacs shell tries to keep a shell buffer's cwd in sync with the shell's but easily gets out of sync. I have used the tramp interface and it's OK. I wonder how useful this would really be; I typically run a bunch of things remotely and then have the result pipe back into a local executable. Thus anything that ran the pipeline remotely by default would need some quotology to differentiate the two, which exists now.

Just need to wait for a shell with native support for ssh

gumby 6y ago

What would that look like? I’ve never felt constrained by just calling ssh.

dan-robertson 6y ago
1. When you ssh you get to continue with the benefits and syntax of your current shell. The closest I know to this is eshell which gets some access to remote hosts through tramp rather than ssh. 2. There’s a small family of commands that take commands as arguments, eg env, xargs, parallel, find, ssh. Maybe they should get special support and the shell should allow you to write subshells to be passed to these commands in some first-class way, similar to the way bash magically converts <(...) into a special file name arg with a process running redirected to that file
- gumby 6y ago
  Ah, I get it. Right now I just run commands remotely by prefixing ssh (actually I have aliases for the commonly connected machines). So it's ls for local list and ssh remote ls for remote's ls (actually I type remote-name ls ). So things like $! or ^ work as expected since they operate normally, but some quoting is indeed required (e.g. I usually want a pipeline to run entirely, or mostly, remotely). But as each invocation invokes a fresh shell the remote connection is stateless. It would be nice if the shell could track things like remote cd and prefix subsequent commands with `cd`. This is hard to get right; there are so many ways to cd or pushd/popd (especially in `()` sub shells or with !:xx kinds of shortcuts) that they are hard to find. Emacs shell tries to keep a shell buffer's cwd in sync with the shell's but easily gets out of sync. I have used the tramp interface and it's OK. I wonder how useful this would really be; I typically run a bunch of things remotely and then have the result pipe back into a local executable. Thus anything that ran the pipeline remotely by default would need some quotology to differentiate the two, which exists now.