| > I was hoping to stick with bash or zsh, and just write processes that somehow communicate out of band, but I think we're still up against the same problem. Yeah we have different starting points but very much similar problems. tbh idea behind my shell wasn't originally to address typed pipelines, that was just something that evolved from it quite by accident. Anyhow, your suggestion of overwriting / aliasing `ssh` is genius. Though I'm thinking rather than tunnelling a TCP connection, I could just spawn an instance of my shell on the remote server and then do everything through normal pipelines as I now control both ends of the pipe. It's arguably got less proverbial moving parts compared to a TCP listener (which might then require a central data type daemon et al) and I'd need my software running on the remote server for the data types to work anyway. There is obviously a fair security concern some people might have about that but if we're open and honest about that and offer an "opt in/out" where opting out would disable support for piped types over SSH then I can't see people having an issue with it. Coincidentally I used to do something similar in a previous job where I had a pretty feature rich .bashrc and no Puppet. So `ssh` was overwritten with a bash function to copy my .bashrc onto the remote box before starting the remote shell. > This idea is, of course, over-engineered as hell. But then again this whole pursuit is. Haha so true! Thanks for your help. You may have just solved a problem I've been grappling with for over a year. |