If the user does something accidentally like:
$> cat some_large_file
pressing CTRL+C does not immediately stop the stream of text that is scrolling by.
Doing the same in putty does stop the stream; tunnelier should support this feature
Sunday, October 02, 2011
Tunnelier does send Ctrl+C immediately as soon as you press it, and the server will react to it by stopping the command that's being executed.
The issue is most likely that Tunnelier implements the SSH session in such a way that the server is permitted to send a large amount of data for the client to process. When you press Ctrl+C, the server stops the process, but there's already 500 kB of data buffered up at the client that needs to be shown. Windows console output is slow, and it takes a while for Tunnelier to display the outstanding data.
It would not make sense for Tunnelier to throttle the amount of data the server can send, because that would reduce the performance of SFTP transfers. The real problem seems to be the slowness of Windows console output. This is something we can't address in the short term, but we plan to implement our own console that will be more like PuTTY, and hopefully faster than the Windows console, in the long run.
If it's not difficult, the client should just discard 500 kB of data buffered up.
Tuesday, October 04, 2011
Well, I for one would be willing to accept that as a risk when I hit CTRL+C. The reason being, there is a quick fix:
And this situation is one of the things that "stty sane" was designed for.
So my suggestion/request would be to add a new option:
"Dump queued output upon <ctrl-c>"
to the settings available in the "Terminal Session" section of the "Terminal" tab. And leave if off by default.
If you need someone to beta-test the new option, I'm happy to help, as solving this very annoying issue would put Tunnelier head-and-shoulders above all the other solutions in my book.
Friday, October 07, 2011
This topic is archived. No further replies will be accepted.Other recent topics