4 ms·

This tool demonstrates that POSIX shells are at the wrong layer of the stack. The shell should be part of the user interface (e.g. the terminal emulator or con

This tool demonstrates that POSIX shells are at the wrong layer of the stack. The shell should be part of the user interface (e.g. the terminal emulator or console), not a program running on the remote system.

Aperocky 5y ago
> program running on the remote system. Simple is better than complex. Sure the shell might have looked amazing like a browser but why
- convolvatron 5y ago
  hardly more complex. imagine if the operating state was expressed in some common data format - just imagine tables. and the shell then is my local preference that interacts with that data model. is that less or more complicated than the mishmash of oddly designed kernel interfaces we have today (fork. mmap. ptrace....so much of it is a mess) not only would that clean up the lot, and allow for a very straightforward remote indirection, but would open up all kinds of lovely usages like being able to trivially capture and replay command streams. interposition. general purpose rewrites. a well-defined domain in which to upgrade and downgrade the interface schema. and more things I'm sure I've never thought of.
  - hulitu 5y ago
    And imagine that you have a bug. And that you trash the filesystem remotely but by you it looks ok. Nobody asks you to use a shell with ssh. You can use X or (when or if will ever suport such an outdated feature) wayland.
- danielheath 5y ago
  plan9 achieved exactly this, and with a far simpler design. Backwards compatible is better than simple.
- strager 5y ago
  > Sure the shell might have looked amazing like a browser but why So you don't need to copy your config to the remote server, like XXH does. So you can still edit your command when your wifi gets spotty.
jolmg 5y ago
It is part of the user interface of the server as it is.
- 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.
deleted 5y ago
[deleted]
hulitu 5y ago
Why ? You have the browser for such things. In UNIX a shell is a shell, a console is a TTY (that's where the output of a shell mostly goes) and a terminal emulator is a TTY emulator.
- strager 5y ago
  > You have the browser for such things. I think the use case of a browser and a shell is quite different. I don't know what a browser would look like if it had an easily-scrollable log like a terminal does. I think you have a good point about a browser being a GUI version of the shell. I'm not proposing a GUI shell, though, but a shell which lets me run TUI/console programs.
jeroenhd 5y ago
I don't think so. As much as I like oh-my-zsh, I wouldn't want its massive code base and attack surface to be forwarded to sensitive or critical servers. Shells require integration with the rest of the system, which involves automatically executing certain scripts based on program availability for autocomplete. That's difficult to do when you don't know what kind of system you're remoting into. You can't reuse the same configuration for remoting into an old Ubuntu 12.04 machine and for remoting into a Windows 11 powershell prompt without losing most functionality you want out of a more-than-basic shell. If you want a unified shell, you'd probably want to set up a layer between the user interface and SSH (on both sides) to make this possible.
- strager 5y ago
  > I wouldn't want [oh-my-zsh's] massive code base and attack surface to be forwarded to sensitive or critical servers. I think we agree here. I said "The shell should [not be] a program running on the remote system." > You can't reuse the same configuration for remoting into an old Ubuntu 12.04 machine and for remoting into a Windows 11 powershell prompt without losing most functionality you want out of a more-than-basic shell. Why not? Why couldn't a single shell program understand PowerShell objects, Windows and Linux environment variables, and Bash/Fish/Zsh completion scripts?
  - jeroenhd 5y ago
    I suppose it could, but you'd be building several shell languages into a single program to support it, including support for the necessary aliasing and macros that system shells (ab)use for system configuration. I think the system you propose would require a fat server to properly serialize the necessary contents back to the user's shell. In effect you'd be writing a replacement for an ssh server with deep integration into whatever shell the user is running locally. The alternative, constantly dumping the shell state and interpreting it, would be easy to get wrong, and desyncs of local and remote state could have a severe impact on the commands you run. It's not technically impossible, just very impractical. I think it also goes against the philosophy of "do one thing and do it right" because of all the moving parts.

Aperocky 5y ago

> program running on the remote system. Simple is better than complex. Sure the shell might have looked amazing like a browser but why

convolvatron 5y ago
hardly more complex. imagine if the operating state was expressed in some common data format - just imagine tables. and the shell then is my local preference that interacts with that data model. is that less or more complicated than the mishmash of oddly designed kernel interfaces we have today (fork. mmap. ptrace....so much of it is a mess) not only would that clean up the lot, and allow for a very straightforward remote indirection, but would open up all kinds of lovely usages like being able to trivially capture and replay command streams. interposition. general purpose rewrites. a well-defined domain in which to upgrade and downgrade the interface schema. and more things I'm sure I've never thought of.
- hulitu 5y ago
  And imagine that you have a bug. And that you trash the filesystem remotely but by you it looks ok. Nobody asks you to use a shell with ssh. You can use X or (when or if will ever suport such an outdated feature) wayland.
danielheath 5y ago
plan9 achieved exactly this, and with a far simpler design. Backwards compatible is better than simple.
strager 5y ago
> Sure the shell might have looked amazing like a browser but why So you don't need to copy your config to the remote server, like XXH does. So you can still edit your command when your wifi gets spotty.

jolmg 5y ago

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

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.

deleted 5y ago

[deleted]

hulitu 5y ago

Why ? You have the browser for such things. In UNIX a shell is a shell, a console is a TTY (that's where the output of a shell mostly goes) and a terminal emulator is a TTY emulator.

strager 5y ago
> You have the browser for such things. I think the use case of a browser and a shell is quite different. I don't know what a browser would look like if it had an easily-scrollable log like a terminal does. I think you have a good point about a browser being a GUI version of the shell. I'm not proposing a GUI shell, though, but a shell which lets me run TUI/console programs.

jeroenhd 5y ago

I don't think so. As much as I like oh-my-zsh, I wouldn't want its massive code base and attack surface to be forwarded to sensitive or critical servers. Shells require integration with the rest of the system, which involves automatically executing certain scripts based on program availability for autocomplete. That's difficult to do when you don't know what kind of system you're remoting into. You can't reuse the same configuration for remoting into an old Ubuntu 12.04 machine and for remoting into a Windows 11 powershell prompt without losing most functionality you want out of a more-than-basic shell. If you want a unified shell, you'd probably want to set up a layer between the user interface and SSH (on both sides) to make this possible.

strager 5y ago
> I wouldn't want [oh-my-zsh's] massive code base and attack surface to be forwarded to sensitive or critical servers. I think we agree here. I said "The shell should [not be] a program running on the remote system." > You can't reuse the same configuration for remoting into an old Ubuntu 12.04 machine and for remoting into a Windows 11 powershell prompt without losing most functionality you want out of a more-than-basic shell. Why not? Why couldn't a single shell program understand PowerShell objects, Windows and Linux environment variables, and Bash/Fish/Zsh completion scripts?
- jeroenhd 5y ago
  I suppose it could, but you'd be building several shell languages into a single program to support it, including support for the necessary aliasing and macros that system shells (ab)use for system configuration. I think the system you propose would require a fat server to properly serialize the necessary contents back to the user's shell. In effect you'd be writing a replacement for an ssh server with deep integration into whatever shell the user is running locally. The alternative, constantly dumping the shell state and interpreting it, would be easy to get wrong, and desyncs of local and remote state could have a severe impact on the commands you run. It's not technically impossible, just very impractical. I think it also goes against the philosophy of "do one thing and do it right" because of all the moving parts.