Also the problem here isn’t that iterm2 is trying to emulate terminals, it’s that it’s trying to do something more over the same network connection without making changes to the ssh protocol.
Also the problem here isn’t that iterm2 is trying to emulate terminals, it’s that it’s trying to do something more over the same network connection without making changes to the ssh protocol.
what we really want is being able to pipe semantic data that can be output to some kind of graphical device/interface that uses that semantic information to display the data using nice graphical interface elements.
How about Arcan?
It seems to me that you are conflating the role of the terminal with the role of the shell. The terminal accepts streams of text and commands to instruct the terminal, so that software can accept input and present output. It doesn't fundamentally need to be aware of the concepts of pipes and commands to do that.
Of course, that doesn't stop iTerm2 from doing RCE by design, but at a conceptual level this is not a problem inherent to a terminal.
What is it specifically that you want to do which your favorite shell doesn't allow because it is restricted by terminals?
Maybe you'd be interested to learn about plan9's graphical terminal. Its window manager runs entirely within it, and all windows just represent multiplexed access to limited areas of the terminal.
correct. the in-band sequences are dangerous and unwieldy. they don't convey enough information. they are a hack to work within the limitations if historical terminals. that's what this whole thread is about.
a separate graphics channel creates a separate window. then you have two windows. not good either. it needs to be one window, and considering that this window should be able to support multiple remote connections it needs to be local otherwise i would get a new window for each server i connect to. that works for some people, but not for me. and it needs to work through a single channel like ssh/mosh or another similar protocol and be forwardable.
so i want a third option. one approach is sending semantic data, letting the terminal interpret it and display it graphically. this is interesting because shells are already exploring semantic data. (elvish, murex, nushell, others...)
plan9 sounds interesting. i see several efforts to port aspects of it to linux. they all seem to have stalled. more work needs to be done here. that's what i am advocating.