4 ms·

> 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

> 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.
- strager 5y ago
  > 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.

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.

strager 5y ago
> 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.