2

In a shell script, if I source even a trivial vim script this way

$ cat ascript 
:q

$ cat test
vim -S ascript -N -u NONE
read

This is what I get when I run it:

$ bash test
^[[I

The ^[[I output is unexpected and breaks the further logic of my shell script.

Does anyone guess/know the nature of it and a possible way to eliminate that effect?

upd1

zsh test output is the same, sh does not work for other reason.

$ zsh test
^[[I

$ sh test
test: 2: read: arg count

And just for completeness:

"Debian GNU/Linux 11 (bullseye)"
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 01 2021 01:51:08)

upd2

After trying to reproduce on other systems:

A shorter way is

vim -c ': quit' ; read

which may or may not provide you with some garbage output, ^[[I is just one of the examples, another possible is ^[[2;2R^[]11;rgb:3838/3b3b/4040^G. So the other fact I figured out, the issue is not there if one works in a tmux session. That made me think towards the matter of vim (mis?)handling the terminal settings. And indeed changing TERM from default xterm-256color to screen-256color makes the issue resolved, or rather worked around. To resolve it right way, one probably should find a proper combination of terminal-options.

Improve this question
4
  • I cannot reproduce the error on CentOS 7.9 and vim 7.4. Out of curosity, does it work if you try sh test or zsh test? Commented Dec 25, 2022 at 16:52
  • I've updated the question. Commented Dec 25, 2022 at 17:59
  • What are you trying to achieve with your use of vim? There may be a better tool for noninteractive use Commented Dec 25, 2022 at 20:12
  • This is retrieving of the MRU list by :browse old but not interactively, using vim's redir. This is actually done long time ago and works fine excluding for cases like in this question. Commented Dec 25, 2022 at 20:32

1 Answer 1

Reset to default
2

Some terminals, including xterm, can be configured to send applications a control sequence when the terminal gains or loses focus: ^[[I when the terminal becomes focused and ^[[O when the terminal stops being focused. Turn this feature off with the control sequence ^[[?1004l (under CSI ? Ps l in the ctlseqs list), or don't turn it on in the first place (it's off by default), or configure some application (Vim?) not to do it.

^[[2;2R is the terminal reporting its color palette (documented under CSI # R in the ctlseqs document). This only happens when an application running in the terminal requests it (again presumably Vim in your case). ^[]11;rgb:3838/3b3b/4040^G is a response to an OSC query which again is initiated by an application.

Vim under Debian appears to be configured with mouse support turned on by default, even with -u NONE. I think that's the cause of your problem. (I can't reproduce it but I'm not in xterm right now.) I'm not a Vim expert, but I think you can run :set ttymouse= or :set t_RV= in Vim to turn it off (this needs to be done during initialization, so in .vimrc or in a -S script: if done interactively, it's too late).

Note on notation: in this answer, I use ^[ for an escape character (\033 in printf, $'\e' in bash or zsh). In the xterm documentation, CSI stands for the two-character sequence ^[[.

Improve this answer
3
  • Unfortunately, set nottymouse is not a valid option on my systems, giving E474: Invalid argument: nottymouse. I can however work around it similarly with vim -c ':set ttytype=screen-256color | :quit ' ; read and perhaps have to play with this more to figure out a more decent general solution if that posssible at all. Thanks anyway! Commented Dec 25, 2022 at 20:22
  • @Tagwint Apologies, it would be set ttymouse= since that's not a boolean option. Lying about the terminal type has the same effect. Commented Dec 26, 2022 at 9:41
  • my late acceptance :) Thank you! Commented Feb 15, 2023 at 21:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.