tmux itself responds to DA and DA2 with: DA - \033[?1;2c DA2 - \033[>0;95;0c
On Mon, Apr 09, 2012 at 07:59:38AM +0100, Nicholas Marriott wrote: > The sequence '\e[77;10003;0c' is not a typical response to either > primary or secondary DA. For example xterm responds: > > $ printf '\e[c';cat > ^[[?1;2c > $ printf '\e[>c';cat > ^[[>0;261;0c > > Which are the same as the possibilities from: > > http://vt100.net/docs/vt220-rm/chapter4.html#S4.17.1 > > tmux sends secondary DA only on terminals which it thinks is xterm (that > is, TERM is an entry with the XT flag) to work out the xterm version. > > If mintty is going to use TERM=xterm, I would strongly recommend it > respond to the secondary DA with '\033[>X;95;0c'. 95 is the lowest > version xterm will respond with and pretty much signals that this > terminal is compatible with basic xterm. > > Else there may be some confusion when xterm gets to version 10003 ;-). > > In the meantime you could probably get around this by doing: > > set -g terminal-overrides 'xterm*:XT@' > > > > On Sun, Apr 08, 2012 at 11:42:40PM +0100, Michael Simpson wrote: > > fyi please see forwarded message below.* > > Issue started after recently upgrading to -current > > Term is xterm everywhere (except of course within tmux) > > Using tmux within OpenBSD having used ssh from Cygwin to get to OBSD box. > > When starting or re-attaching tmux session I get a series of numbers > > printed after the command prompt.* > > Please let me know what info I can provide.* > > > > ---------- Forwarded message ---------- > > From: Andy Koppe > > Date: Sunday, April 8, 2012 > > Subject: TERM problem with mintty and latest tmux in OpenBSD > > To: Michael Simpson <[1]mikie.simp...@gmail.com> > > > > On 5 April 2012 23:51, Michael Simpson wrote: > > > On 5 April 2012 12:53, Andy Koppe wrote: > > >> On 30 March 2012 10:03, Michael Simpson wrote: > > >>> On 29 March 2012 06:29, Andy Koppe wrote: > > >>> > > >>>> I don't see any evidence here that this is a problem with mintty > > >>>> rather than OpenBSD's tmux or xterm terminfo entry. Can you try this > > >>>> using Cygwin's xterm? > > >>> > > >>> Cygwin's xterm works as expected > > >> > > >> Thanks for checking. Sounds like a mintty incompatibility with xterm > > >> then. I'll need your help to try to narrow down the issue though, as I > > >> haven't got access to an OpenBSD system. > > >> > > >> Can you invoke mintty with the --log option for logging output into a > > >> file, do as little as possible to reproduce the problem, and send the > > >> resulting log? The aim here is that I can cat the log file to see the > > >> issue and then try to narrow it down to the problematic control > > >> sequence. > > >> > > >> Regards, > > >> Andy > > > > > > Hi Andy > > > > > > sorry for the late response > > > > Don't be silly, it's me who's being slow here. > > > > > I have attached the log file > > > what i did was ssh to the openbsd box then startede a tmux session, > > > detached from it and reattached then ^d'd both it and the ksh shell > > > back to the originating box > > > > Thanks very much. I've had a look at this, and I don't think this is a > > mintty issue after all. Tmux is requesting the terminal's > > identification code using the control sequence "\e[>c" (where \e > > stands for the ESC character). Mintty replies with its identification > > sequence: "\e[77;10003;0c", whereby 77 is the ASCII code for M and > > 10003 is the mintty version 1.0.3 encoded as > > 10000*major+100*minor+patch. > > > > I'm assuming it's that which you're seeing on the command line, so for > > some reason tmux is letting mintty's response through to the shell as > > keyboard input instead of processing it itself. It requests the ID > > code not just on reattach but also when originally starting the > > session, so maybe it's a timing issue if this doesn't happen when > > creating the session. > > > > Please report this to the tmux developers. > > > > Regards, > > Andy > > > > > > > > Hope this is of use and please let me know what else i can do > > > > > > > > regards > > > mike > > > > References > > > > Visible links > > 1. javascript:_e({}, 'cvml', 'mikie.simp...@gmail.com'); > > > ------------------------------------------------------------------------------ > > For Developers, A Lot Can Happen In A Second. > > Boundary is the first to Know...and Tell You. > > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > > http://p.sf.net/sfu/Boundary-d2dvs2 > > > _______________________________________________ > > tmux-users mailing list > > tmux-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/tmux-users > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
