4 ms·

> Expect this stuff to change drastically in the next 5 years. Bwahaha... is this your first encounter with backwards compatibility? Changing this would be ve

> Expect this stuff to change drastically in the next 5 years. Bwahaha... is this your first encounter with backwards compatibility? Changing this would be very hard, but this has nothing to do with somebody embracing some grand philosophy, but with tons of existing software relying on Unix like systems to, well ... be Unix-like, because that's what the software was written for.

Ericson2314 6y ago
I've given it a lot of thought, and below is my one "reformist" idea to significantly improve things without breaking back compat so bad Invert the shell and terminal: every shell command (with unredirected streams) gets it's own pty. - Like the those repl "notebooks" you can scroll each output separately, without hacks. - Backgrounded processes won't spew garbage when you are trying to type. They just continue running in their terminal. You can even background something like vim or a game that takes the whole terminal, and it's just fine! - Rather than hacking scroll back onto processes that might use tty stuff in expected ways, just straight-jacket them by giving them plain pipes instead! The OP exploits are then opt-in impossible. - Having powershell-esque "post-text" commands that dispense with the bullshit are far easier to manage: also give them regular file descriptors and negotiate protocol or whatever, just like the above, rather than a pty. - stdin can be a nice form with submit button rather than fixed (usually line) buffering policy. - shell might even be simpler as there is less careful juggling of shared resources except where the programmer asks for it. I also use ssh multiplexing instead of tmux for extra shells. When I do need to use tmux, I hate that read only mode prevents scrollback. The above builds nicely upon this: - The persistent remote shell has as many ptys as needed before for chained commands which might still be running, or separate "sessions" - The local client can use native UI elements for everything, no TUI jank. - Scrolling over many (live or saved) terminals, the normal scrollback case, is possible and very side-effect free. Anyone see any issues? I don't for anything I do daily (git, coretuils, etc.)! I don't think I have time to make this, so please someone else do.
- spijdar 6y ago
  It's not a direct match, but I think you'd be fascinated by aspects of Plan9's model. It certainly comes closer to what you've described than Unix does. Depending on exactly what you mean or you're envisioning, it might be really close. The problem, of course, is this either breaks existing software or requires new software to be written from scratch to utilize the new frameworks. This was (one of) the reasons plan9 never gained much traction, and the big hurdle for any contender to the TTY/shell throne. (It's also worth pointing out microsoft themselves reworked their terminal interfaces to be more unix-like for this very reason -- software compatibility)
- CGamesPlay 6y ago
  I’ve given this a lot of thought over the years and the biggest conclusion I have is that there’s no real “killer feature” in any of this that makes it spectacular, and maintaining backwards compatibility would be critical to let anybody use it. Still, I like the idea of splitting each command into a separate PTY, I wonder how good a TUI replacement for tmux built around this could be (yes, gotta start with the TUI before you think about a completely new GUI, again for the interop).
- darrenf 6y ago
  > You can even background something like vim or a game that takes the whole terminal, and it's just fine! Focusing on this point, you can background vim just fine right now - I have tons of vim processes backgrounded all the time.
  - nybble41 6y ago
    You can suspend vim. If you try to run it in the background (e.g. with the bg command) then it just suspends itself again. To actually run it in the background on a shared terminal you need something like screen or tmux… which assigns the process its own pty. Perhaps for most use cases involving vim it doesn't make that much difference—what would it be doing in the background anyway?—but there are other TUI programs that could be doing useful processing in the background if they didn't need to share the pty with other processes.
- 6y ago
junon 6y ago
No, I'm saying this because there exists mailing lists and chat rooms where all of the terminal emulator developers are discussing these problems to collectively solve this issue.

Ericson2314 6y ago

I've given it a lot of thought, and below is my one "reformist" idea to significantly improve things without breaking back compat so bad Invert the shell and terminal: every shell command (with unredirected streams) gets it's own pty. - Like the those repl "notebooks" you can scroll each output separately, without hacks. - Backgrounded processes won't spew garbage when you are trying to type. They just continue running in their terminal. You can even background something like vim or a game that takes the whole terminal, and it's just fine! - Rather than hacking scroll back onto processes that might use tty stuff in expected ways, just straight-jacket them by giving them plain pipes instead! The OP exploits are then opt-in impossible. - Having powershell-esque "post-text" commands that dispense with the bullshit are far easier to manage: also give them regular file descriptors and negotiate protocol or whatever, just like the above, rather than a pty. - stdin can be a nice form with submit button rather than fixed (usually line) buffering policy. - shell might even be simpler as there is less careful juggling of shared resources except where the programmer asks for it. I also use ssh multiplexing instead of tmux for extra shells. When I do need to use tmux, I hate that read only mode prevents scrollback. The above builds nicely upon this: - The persistent remote shell has as many ptys as needed before for chained commands which might still be running, or separate "sessions" - The local client can use native UI elements for everything, no TUI jank. - Scrolling over many (live or saved) terminals, the normal scrollback case, is possible and very side-effect free. Anyone see any issues? I don't for anything I do daily (git, coretuils, etc.)! I don't think I have time to make this, so please someone else do.

spijdar 6y ago
It's not a direct match, but I think you'd be fascinated by aspects of Plan9's model. It certainly comes closer to what you've described than Unix does. Depending on exactly what you mean or you're envisioning, it might be really close. The problem, of course, is this either breaks existing software or requires new software to be written from scratch to utilize the new frameworks. This was (one of) the reasons plan9 never gained much traction, and the big hurdle for any contender to the TTY/shell throne. (It's also worth pointing out microsoft themselves reworked their terminal interfaces to be more unix-like for this very reason -- software compatibility)
CGamesPlay 6y ago
I’ve given this a lot of thought over the years and the biggest conclusion I have is that there’s no real “killer feature” in any of this that makes it spectacular, and maintaining backwards compatibility would be critical to let anybody use it. Still, I like the idea of splitting each command into a separate PTY, I wonder how good a TUI replacement for tmux built around this could be (yes, gotta start with the TUI before you think about a completely new GUI, again for the interop).
darrenf 6y ago
> You can even background something like vim or a game that takes the whole terminal, and it's just fine! Focusing on this point, you can background vim just fine right now - I have tons of vim processes backgrounded all the time.
- nybble41 6y ago
  You can suspend vim. If you try to run it in the background (e.g. with the bg command) then it just suspends itself again. To actually run it in the background on a shared terminal you need something like screen or tmux… which assigns the process its own pty. Perhaps for most use cases involving vim it doesn't make that much difference—what would it be doing in the background anyway?—but there are other TUI programs that could be doing useful processing in the background if they didn't need to share the pty with other processes.
6y ago

junon 6y ago

No, I'm saying this because there exists mailing lists and chat rooms where all of the terminal emulator developers are discussing these problems to collectively solve this issue.