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][email protected]> > > 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', '[email protected]'); > ------------------------------------------------------------------------------ > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/tmux-users
