(Can I post to vim_dev? I'm not subscribed. Let's find out.)
Christian Brabandt replied to me:
>> $ ex ~/.vimrc
>> "~/.vimrc" 14L, 212C
>> Entering Ex mode. Type "visual" to go to Normal mode.
>> :^[[>41;297;0c
>> The ^[ is an escape. This looks like an attempt by vim to send a
...
> That is the xterm version string. I am not sure what happens and I don't
> know the code good enough. At a quick glance at term.c it looks like
...
> You might want to enable debugging in term.c and see, if the log can
> help you figuring out what was wrong.
I did just that today, after failing to find a distro built vim for
which would not reproduce the bug in the most stripped down form (no
user dot files and "-c 'set ttym='").
What I've learned:
0) I can compile vim 7.1, 7.1, and 7.2, but they all die on startup.
1) With vim7.3, unpatched source, it occurs with
configure --with-features=huge ---disable-gui
configure --with-features=big ---disable-gui
but not
configure --with-features=normal ---disable-gui
2) It doesn't happen with
vim -u NORC -c 'set ttym='
It doesn't happen after
root# chmod 000 /usr/share/vim/vimrc
user$ mv ~/.vimrc ~/.vimrc.hold
user$ vim -c 'set ttym='
But if I have no system vimrc a user vimrc of just "set ttym="
then it will happen. I haven't tried "set ttym=" in the system
vimrc.
3) With strace, I see that it happens after ~/.viminfo is read the
second time. (Deleting ~/.viminfo doesn't change the behavior.)
Simplifed the trace looks like:
execve("/usr/bin/vim", ["vim", "-c", "set ttym=",
"/home/testuser/.vimrc"], [/* 46 vars */]) = 0
[much happens ...]
write(1, " 1L, 10C", 8) = 8
open("/home/testuser/.viminfo", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, ...}) = 0
mmap2(NULL, 4096, ...) = 0xb76cc000
read(3, "# This viminfo file was generate"..., 4096) = 4096
[multiple reads omited...]
close(3) = 0
munmap(0xb76cc000, 4096) = 0
select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
getcwd("/tmp/vim-tests", 4096) = 15
ioctl(1, SNDCTL_TMR_TIMEBASE ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE ...}) = 0
write(1, "\33[>c", 4) = 4
select(1, [0], NULL, [0], {0, 0}) = 1 (in [0], left {0, 0})
read(0, "\33[>41;297;0c", 4096) = 12
select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
select(1, [0], NULL, [0], {0, 0}) = 0 (Timeout)
write(1, "\33[1;1Hset sw=72\r\n\33[1m\33[34m~ "..., 1944) = 1944
That's vim writing the size of the file out (" 1L, 10C"), opening
and reading viminfo, checking the working directory for about the
15th time, setting some tty ioctl()s, then it writes an escape
sequence ("\33[>c"), detects (with select()) there is a response and
reads that response in ("\33[>41;297;0c"), checks a few more times
for input and then writes the file on the screen for the first time.
The escape sequence "\33[>c" apparently prompts xterm to reply with
a version escape sequence, which is read but not processed as a
terminal response, and is instead treated as user input.
I have not yet pinned down what function is sending that escape
sequence. In my observations, .viminfo is read three times and written
once. As mentioned, if .viminfo is missing the same actions occur,
except that the open(...viminfo...) fails and the contents are not
read, but this still happens after the second attempt to open it, with
the same interleaves of write(1...), select(), and read(0...).
My next plan of attack is stepping through the code after the open
of .viminfo to try to find where it is happening, but I ran out of time
today.
Elijah
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment