EDIT: If you use screen or tmux, I suppose that you probably don’t need software flow control anyway from a UI standpoint, because both will suspend flow if you enter their copy mode, which acts similarly.
EDIT2: I suppose that the utility of software flow control is probably rather reduced today from its original role. At one point in time, the rates at which data could be sent to the terminal was low enough that it wasn’t a particularly large issue to suspend it while interesting information was still on the screen. I certainly remember some relatively-slow terminal systems, especially with control sequences mixed in; BBSes took advantage of the fact that it took time for ANSI art to be transmitted at 9600 baud modem connections or so to make the display of an image something of an animated, vertically-scrolling banner; you’d have banners that were rather vertically-larger than the typical display, but moved slowly-enough to watch as they scrolled by. But today, a large chunk of software can throw text at the terminal so quickly that, unless its performance is otherwise-constrained, one has little chance of stopping flow while the information one wants is visible. Only really useful if the software naturally has stops at useful places and one can suspend flow there, and I don’t know what percentage of cases that comes up with. Maybe there’s an argument to default to not having software flow control any more.
Advanced advanced Linux user: “Ctrl+S shit what’s the unsuspend button”
Control-Q
Or you can disable software flow control in cooked mode with
stty -ixonand then Control-S won’t suspend flow.EDIT: If you use
screenortmux, I suppose that you probably don’t need software flow control anyway from a UI standpoint, because both will suspend flow if you enter their copy mode, which acts similarly.EDIT2: I suppose that the utility of software flow control is probably rather reduced today from its original role. At one point in time, the rates at which data could be sent to the terminal was low enough that it wasn’t a particularly large issue to suspend it while interesting information was still on the screen. I certainly remember some relatively-slow terminal systems, especially with control sequences mixed in; BBSes took advantage of the fact that it took time for ANSI art to be transmitted at 9600 baud modem connections or so to make the display of an image something of an animated, vertically-scrolling banner; you’d have banners that were rather vertically-larger than the typical display, but moved slowly-enough to watch as they scrolled by. But today, a large chunk of software can throw text at the terminal so quickly that, unless its performance is otherwise-constrained, one has little chance of stopping flow while the information one wants is visible. Only really useful if the software naturally has stops at useful places and one can suspend flow there, and I don’t know what percentage of cases that comes up with. Maybe there’s an argument to default to not having software flow control any more.
Ctrl+S works in Nano now.