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 <mikie.simp...@gmail.com <javascript:_e({}, 'cvml',
'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
------------------------------------------------------------------------------
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
