0

On a local terminal, the stty -noflsh option allows to discard buffered output on Ctrl-C and thus prevents from long scrolling delays if one did accidentally output large amounts of text to the terminal.

How to achieve that on a ssh session where the local terminal is in raw mode and thus does not interpret Ctrl-C as interrupt, while the remote pty has already forwarded large quantities of text through the ssh network connection before the interrupt occurs ?

This problem (long scrolling delays even after pressing Ctrl-C) occurs if the network speed is way higher than the scrolling speed of the terminal, which seems to be true anytime as of today, and the buffers in the network connection are large compared to that scrolling speed, which also seems to be true anytime as of today.

Improve this question
4
  • Which terminal are you using? There can easily be a ~1000x performance difference among them. The fastest one can process about 40 MByte/s, most modern terminals can do around 10-20 MB/s on my pretty average laptop. See gitlab.gnome.org/GNOME/vte/-/issues/334#note_2078377. The active Linux console (vt) is notoriously slow, if you're using that then switch to another vt for a sec. If you're using a graphical one, just open a new one and let the old one complete its job in the background. I assume you face this problem rarely enough that it may not need a more sophisticated solution.
    – egmont
    Commented Apr 14 at 15:32
  • @egmont, I'm facing this problem often enough that I'm in fact seeking a sophisticated solution here instead of any of the workarounds that you mentioned. Most time, I'm using cygwin or linux (VT) as terminals, but I expect a solution, if any, to be independent of teminal type.
    – Juergen
    Commented Apr 18 at 11:49
  • I'm not familiar with cygwin. The Linux VT, as linked above, is about 1000x(!) slower than the fastest graphical terminal out there. I don't think it's a wise thing to look for a solution at other places, and at the same time refuse to switch to a much faster terminal. But back to your question... I don't know the solution, I'm just thinking out loud. You have a very slow terminal, and someone remote producing tons of data. As the data traverses, there are a lot of components that buffer up a bit of it. I'm not a netowrk expert of all levels, but I expect that active network elements ...
    – egmont
    Commented Apr 18 at 12:07
  • ... (e.g. routers, ethernet cards etc.) buffer up a bit of it, and so does the emitter operating system's kernel, ssh (both the server and the client) etc. Since your terminals is very slow, the moment you hit Ctrl+C most of the data hasn't even been printed by your app, and won't be because it receives that Ctrl+C very soon and aborts. But the data that's already there in various buffers (network devices, kernels, ssh etc.) consists of relatively small chunks scattered around at various places, on various layers. I don't have an idea how to purge all of them, seems hopeless to me.
    – egmont
    Commented Apr 18 at 12:09

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .