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.
The shell should be part of the user interface (e.g. the terminal emulator or console), not a program running on the remote system.
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.
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?
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.
I think we could get away without system-configured aliases and macros.
> I think the system you propose would require a fat server
Yup, this sounds about right.
> I think it also goes against the philosophy of "do one thing and do it right" because of all the moving parts.
Agreed. But Clang+LLVM and Visual Studio Code show that discarding this philosophy can lead to a successful project anyway.
It only gets hokey when you reference files as it’s all remote.
Except shell itself is an abstraction over a computer by encapsulating system APIs.
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.
* 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.
(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?
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.
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.
Simple is better than complex.
Sure the shell might have looked amazing like a browser but why
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.
Backwards compatible is better than simple.
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.