XXH: Bring your favorite shell wherever you go through the SSH
github.com
github.com
The shell should be part of the user interface (e.g. the terminal emulator or console), not a program running on the remote system.
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.
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.
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.
A simplistic version could be just to ship a static binary of your shell over, like:
tar -cf - ./bash-binary | ssh $host 'tar -xf -;./bash-binary -c "echo hello world"'
why would you tar-up a single file w/o compression thou?
Sounds like an awful way to distribute and run software...
At my company we sometimes have to SSH into our dev nodes to restart things, figure out what's going wrong, etc. But we wipe them out nightly to update the code.
This tool would let you keep all your special aliases for working on the nodes without manually copying your config(s) over.
Can't say I'd use it, but I can see use cases like the above.
Lots of engineers are also using the nodes, so you'd need to share that repo with them then have some command you type in each time to load it after you ssh into the node.
And you'd only have updated versions of your rc every night, unless you want to commit a change, push, go to the server to pull it down, reload the shell.
I guess what I'm saying is this tool fills a niche and avoids all the above complexity just for some shell aliases.
(btw I don't really have a use for it, I just have 2 or 3 commands to copy paste into the shell for 99% of what I need to do. Just maintaining the argument to hear alternatives from people!)