Hacker News Reader

Comment by jeroenhd | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com