<story><title>Terminal escape sequences in Git commit email field</title><url>https://twitter.com/ryancdotorg/status/1375484757916672000</url></story><parent_chain><item><author>Ericson2314</author><text>I&amp;#x27;ve given it a lot of thought, and below is my one &amp;quot;reformist&amp;quot; idea to significantly improve things without breaking back compat so bad&lt;p&gt;Invert the shell and terminal: every shell command (with unredirected streams) gets it&amp;#x27;s own pty.&lt;p&gt;- Like the those repl &amp;quot;notebooks&amp;quot; you can scroll each output separately, without hacks.&lt;p&gt;- Backgrounded processes won&amp;#x27;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&amp;#x27;s just fine!&lt;p&gt;- 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.&lt;p&gt;- Having powershell-esque &amp;quot;post-text&amp;quot; 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.&lt;p&gt;- stdin can be a nice form with submit button rather than fixed (usually line) buffering policy.&lt;p&gt;- shell might even be simpler as there is less careful juggling of shared resources except where the programmer asks for it.&lt;p&gt;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:&lt;p&gt;- The persistent remote shell has as many ptys as needed before for chained commands which might still be running, or separate &amp;quot;sessions&amp;quot;&lt;p&gt;- The local client can use native UI elements for everything, no TUI jank.&lt;p&gt;- Scrolling over many (live or saved) terminals, the normal scrollback case, is possible and very side-effect free.&lt;p&gt;Anyone see any issues? I don&amp;#x27;t for anything I do daily (git, coretuils, etc.)! I don&amp;#x27;t think I have time to make this, so please someone else do.</text></item><item><author>st_goliath</author><text>&amp;gt; Expect this stuff to change drastically in the next 5 years.&lt;p&gt;Bwahaha... is this your first encounter with backwards compatibility?&lt;p&gt;Changing this would be &lt;i&gt;very hard&lt;/i&gt;, but this has &lt;i&gt;nothing&lt;/i&gt; to do with somebody embracing some grand philosophy, but with &lt;i&gt;tons&lt;/i&gt; of existing software relying on Unix like systems to, well ... be Unix-like, because that&amp;#x27;s what the software was written for.</text></item><item><author>junon</author><text>I maintain chalk and a slew of other TTY related things.&lt;p&gt;Terminal emulators are, far and away, the most archaic computer technology we still use daily.&lt;p&gt;Believe me when I say, it&amp;#x27;s a very hard problem to solve since everyone has subscribed to Unix&amp;#x27;s philosophy of &amp;quot;everything is text&amp;quot;.&lt;p&gt;As much as I dislike Microsoft&amp;#x27;s philosophies on software, they had the right idea with Powershell. Its execution is just abysmal.&lt;p&gt;Expect this stuff to change drastically in the next 5 years.</text></item></parent_chain><comment><author>darrenf</author><text>&amp;gt; &lt;i&gt;You can even background something like vim or a game that takes the whole terminal, and it&amp;#x27;s just fine!&lt;/i&gt;&lt;p&gt;Focusing on this point, you can background vim just fine right now - I have tons of vim processes backgrounded all the time.</text></comment>
<story><title>Terminal escape sequences in Git commit email field</title><url>https://twitter.com/ryancdotorg/status/1375484757916672000</url></story><parent_chain><item><author>Ericson2314</author><text>I&amp;#x27;ve given it a lot of thought, and below is my one &amp;quot;reformist&amp;quot; idea to significantly improve things without breaking back compat so bad&lt;p&gt;Invert the shell and terminal: every shell command (with unredirected streams) gets it&amp;#x27;s own pty.&lt;p&gt;- Like the those repl &amp;quot;notebooks&amp;quot; you can scroll each output separately, without hacks.&lt;p&gt;- Backgrounded processes won&amp;#x27;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&amp;#x27;s just fine!&lt;p&gt;- 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.&lt;p&gt;- Having powershell-esque &amp;quot;post-text&amp;quot; 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.&lt;p&gt;- stdin can be a nice form with submit button rather than fixed (usually line) buffering policy.&lt;p&gt;- shell might even be simpler as there is less careful juggling of shared resources except where the programmer asks for it.&lt;p&gt;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:&lt;p&gt;- The persistent remote shell has as many ptys as needed before for chained commands which might still be running, or separate &amp;quot;sessions&amp;quot;&lt;p&gt;- The local client can use native UI elements for everything, no TUI jank.&lt;p&gt;- Scrolling over many (live or saved) terminals, the normal scrollback case, is possible and very side-effect free.&lt;p&gt;Anyone see any issues? I don&amp;#x27;t for anything I do daily (git, coretuils, etc.)! I don&amp;#x27;t think I have time to make this, so please someone else do.</text></item><item><author>st_goliath</author><text>&amp;gt; Expect this stuff to change drastically in the next 5 years.&lt;p&gt;Bwahaha... is this your first encounter with backwards compatibility?&lt;p&gt;Changing this would be &lt;i&gt;very hard&lt;/i&gt;, but this has &lt;i&gt;nothing&lt;/i&gt; to do with somebody embracing some grand philosophy, but with &lt;i&gt;tons&lt;/i&gt; of existing software relying on Unix like systems to, well ... be Unix-like, because that&amp;#x27;s what the software was written for.</text></item><item><author>junon</author><text>I maintain chalk and a slew of other TTY related things.&lt;p&gt;Terminal emulators are, far and away, the most archaic computer technology we still use daily.&lt;p&gt;Believe me when I say, it&amp;#x27;s a very hard problem to solve since everyone has subscribed to Unix&amp;#x27;s philosophy of &amp;quot;everything is text&amp;quot;.&lt;p&gt;As much as I dislike Microsoft&amp;#x27;s philosophies on software, they had the right idea with Powershell. Its execution is just abysmal.&lt;p&gt;Expect this stuff to change drastically in the next 5 years.</text></item></parent_chain><comment><author>spijdar</author><text>It&amp;#x27;s not a direct match, but I think you&amp;#x27;d be fascinated by aspects of Plan9&amp;#x27;s model. It certainly comes closer to what you&amp;#x27;ve described than Unix does. Depending on exactly what you mean or you&amp;#x27;re envisioning, it might be &lt;i&gt;really&lt;/i&gt; close.&lt;p&gt;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&amp;#x2F;shell throne.&lt;p&gt;(It&amp;#x27;s also worth pointing out microsoft themselves reworked their terminal interfaces to be more unix-like for this very reason -- software compatibility)</text></comment>