Hi

On Fri, Feb 12, 2010 at 07:59:33PM +1100, Trent W. Buck wrote:
> [Going through the list's archives via gmane...]
> 
> Using tmux 1.1, I still get this kind of behaviour.  The contrived
> example I used was
> 
>     1. start tmux
>     2. ^B%
>     3. for i in {1..99}; do dmesg; done
>     4. ^Bo     (is ignored for a long time)

Nothing we can do about this over ssh since there are buffers between your
client and the terminal that we don't control. It should work better locally.

> I'm still using GNU Screen, with a remote screen session nested inside a
> local screen session, i.e.
> 
>     :screen ssh fs -t screen -dRR
> 
> When I accidentally generate copious output in the remote session, I
> just type
> 
>     ^M~.
> 
> This tells my OpenSSH client to immediately sever its connection.
> Thanks to ":zombie rk onerror" in the local Screen, I can then just hit
> "r" to reconnect to the remote Screen session.  By the time ssh finished
> reconnecting, the remote screen session has finished dealing with the
> copious output.

What's the problem? tmux works the same way.

> 
> 
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> tmux-users mailing list
> tmux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tmux-users

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Reply via email to