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.

> 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?

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.

> including support for the necessary aliasing and macros that system shells (ab)use for system configuration

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 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

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.

I implemented that as a joke, but basically it can work like this: 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.

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.

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?

> The shell should be an abstraction over a computer

Except shell itself is an abstraction over a computer by encapsulating system APIs.

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.

...which of course is an option that Unix provides. "ssh <hostname> <command>" does exactly this.

... 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).

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.

> 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.

> program running on the remote system.

Simple is better than complex.

Sure the shell might have looked amazing like a browser but why

plan9 achieved exactly this, and with a far simpler design.

Backwards compatible is better than simple.

> 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.

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.