4 ms·

It is part of the user interface of the server as it is.

by jolmg 5y ago

bobbylarrybobby 5y ago
I think what the commenter is saying is that you shouldn’t “remote in” to a shell; you should use your regular old shell and have it send commands to a server and display whatever it receives back to you. The shell should be an abstraction over a computer; it shouldn’t be integrally tied to any particular computer as they are today
- koolba 5y ago
  You can do that by running “ssh … — your-command some-arg other-arg | other-command-locally” It only gets hokey when you reference files as it’s all remote.
- Aperocky 5y ago
  > The shell should be an abstraction over a computer Except shell itself is an abstraction over a computer by encapsulating system APIs.
- seanhunter 5y ago
  ...which of course is an option that Unix provides. "ssh <hostname> <command>" does exactly this.
  - strager 5y ago
    ... while sacrificing features like auto-complete, shell awareness (Git branch and other doodads people love to put in their prompt), and persistence (screen/tmux/mosh).
- thaumasiotes 5y ago
  But you can't move the shell across layers. It's needed where it is. The point of the shell is that it's how you issue commands to the computer. You (or GP) want to make the commands independent of the shell. OK. How do you issue your new shell-agnostic commands? How is the computer supposed to understand them? For that to happen, you'll need to implement a shell in the exact place where you just removed the first one.
  - strager 5y ago
    A shell has three parts: * the command editor * the command interpreter/parser * the fork()/exec() calls I think you're talking about the fork()/exec() calls. I'm primarily talking about the command editor.
    - thaumasiotes 5y ago
      OK, so on the server we have a protoshell running which accepts commands and makes system calls. (I don't think your three-part listing makes sense: commands are the input to the shell, and system calls are the output. But you can't separate them -- without input, what output are you producing?) And now, on the client, we have a command editor running which accepts keystrokes and produces commands. But the client runs on a different machine. It doesn't know what commands the protoshell over on the server can accept. How does it know what commands to produce?
  - viraptor 5y ago
    I implemented that as a joke, but basically it can work like this: https://github.com/viraptor/libremotec https://github.com/viraptor/libremotec The app captures syscalls working on FDs and forwards those to the remote side. You could do that in much more clever ways. You can also do it in hacky simple ways like for example ansible does, by just running each command remotely.

It is part of the user interface of the server as it is.

by jolmg 5y ago

It is part of the user interface of the server as it is.

I think what the commenter is saying is that you shouldn’t “remote in” to a shell; you should use your regular old shell and have it send commands to a server and display whatever it receives back to you. The shell should be an abstraction over a computer; it shouldn’t be integrally tied to any particular computer as they are today

koolba 5y ago
You can do that by running “ssh … — your-command some-arg other-arg | other-command-locally” It only gets hokey when you reference files as it’s all remote.
Aperocky 5y ago
> The shell should be an abstraction over a computer Except shell itself is an abstraction over a computer by encapsulating system APIs.
seanhunter 5y ago
...which of course is an option that Unix provides. "ssh <hostname> <command>" does exactly this.
- strager 5y ago
  ... while sacrificing features like auto-complete, shell awareness (Git branch and other doodads people love to put in their prompt), and persistence (screen/tmux/mosh).
thaumasiotes 5y ago
But you can't move the shell across layers. It's needed where it is. The point of the shell is that it's how you issue commands to the computer. You (or GP) want to make the commands independent of the shell. OK. How do you issue your new shell-agnostic commands? How is the computer supposed to understand them? For that to happen, you'll need to implement a shell in the exact place where you just removed the first one.
- strager 5y ago
  A shell has three parts: * the command editor * the command interpreter/parser * the fork()/exec() calls I think you're talking about the fork()/exec() calls. I'm primarily talking about the command editor.
  - thaumasiotes 5y ago
    OK, so on the server we have a protoshell running which accepts commands and makes system calls. (I don't think your three-part listing makes sense: commands are the input to the shell, and system calls are the output. But you can't separate them -- without input, what output are you producing?) And now, on the client, we have a command editor running which accepts keystrokes and produces commands. But the client runs on a different machine. It doesn't know what commands the protoshell over on the server can accept. How does it know what commands to produce?
- viraptor 5y ago
  I implemented that as a joke, but basically it can work like this: https://github.com/viraptor/libremotec https://github.com/viraptor/libremotec The app captures syscalls working on FDs and forwards those to the remote side. You could do that in much more clever ways. You can also do it in hacky simple ways like for example ansible does, by just running each command remotely.