When running a vim instance in gnu screen hitting shift enter in insert mode adds an 'M' and then a newline, rather than just a newline.
Does anybody know what the problem might be, or where to look?
Relevant system info:
Ubuntu 8.04.1
Screen version 4.00.03 (FAU) 23-Oct-06
VIM - Vi IMproved 7.1 (2007 May 12, compiled Jan 31 2008 12:20:21)
Included patches: 1-138
Konsole 1.6.6 (Using KDE 3.5.10)
Thanks to the comments. When checking the value of $TERM I noticed that it was xterm (as expected), but within screen $TERM was set to screen-bce. Setting TERM=xterm after launching screen resolves this issue.
Adding the following to ~/.screenrc solved the problem without having to do anything manually:
term xterm
Missing info from your question:
Where do you run screen and see this issue? Some terminal app (KTerminal, Gnome terminal, virtual console etc) or remote session (eg putty, ssh from another computer)
do a “echo $TERM” and tell us its output
do a “cat -v”, press Shift-Enter, then Enter, then Ctrl-D and then tell us what is output.
First, you could fix your $TERM for within konsole. Install "ncurses-term" and configure konsole to set $TERM=konsole-256color. Then configure screen with "term screen-256color". Or 'konsole' and 'screen', respectively, if that's your preference. Konsole and screen are not xterm and doesn't support everything xterm does, so using incorrect $TERM can lead to bad things.
Related
I'm using CentOS 6. Since the CentOS repos have an older version of vim (7.2), I have compiled my own. However, I am having a weird issue. After running and exiting vim, I've found that my shell prompt has disappeared. Also, when I type, it does not appear in the terminal, nor does any output. What's weird is that it looks as though something is being outputted, since the cursor will move down the screen, but I can't see anything.
It must have something to do with compiling an X version, because it does not happen when I compile vim without X windows support (but I would like to have gvim, too). Here are the configuration options I supplied when compiling:
./configure --prefix=$OPT/Cellar/vim/7.4 --with-features=huge --enable-gui=auto --with-x --enable-xim
I also tried compiling without Xim. I've also tried explicitly setting --enable-gui=gtk2 (which is what gvim 7.2 from the CentOS repos uses).
I am using KDE4. The problem occurs both when running tcsh and bash. I have tried with $TERM set to both xterm and xterm-256color as well.
Additionally, running neither reset nor stty sane restores the shell to its proper behavior.
Any idea why my prompt disappears when running vim? As I missing a config flag or some other compilation issue?
I ultimately traced this down to an error in my ~/.vimrc file. I had some lines like this:
if has('gui_running')
# Gvim customization
endif
if has('gui_gtk2')
# GTK2-specific Gvim customization
endif
The second block was running every time vim loaded. Because it changed some window geometry, it ended up messing up bash; when I dropped back to bash, bash thought it only had ~53 columns to work with (and possibly some other things were messed up).
Solution: The second if block should be inside the first.
I have a redhat machine which I use remotely using putty and this is what have been bugging me a lot now...
Each time I open and close a file with any editor, my prompt shows up on the bottom line without the content of the screen being refreshed. This is really problematic because then I can't see previous outputs that were on the screen just before I opened that file which is still showing up after closing.
Is there a way to fix this. I want it to behave like the gnome-terminal. I don't think this use to happen when I was using an ubuntu server.
I understand that this is the traditional tty behavior, but I don't want it...
Thanks in advance.
If your terminal supports an alternate screen buffer, it should have rmcup and smcup define in its terminfo entry
% infocmp | grep -e rmcup -e smcup
ri=\EM, rmacs=^O, rmcup=\E[2J\E[?47l\E8, rmir=\E[4l,
smcup=\E7\E[?47h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
If enabling altscreen in your .screenrc doesn't fix it, try adding these 2 lines to your .vimrc:
set t_ti=^[[?47h
set t_te=^[[?47l
(note that ^[ is escape, I typed ctrl-v esc)
Vim will echo ti to the terminal on startup and te on exit, instructing the shell/xterm/screen to switch screen buffers.
This post is similar to this and this, however, without putty, the border could display properly. Therefore, I doubt this was caused by an old version of tmux.
I am running FreeBSD 9.2-release and tmux 1.9a (latest on FreeBSD).
I hope someone can give me solution as to why this happens and how to fix it.
I had the same problem with Putty when launching tmux on Linux 12.04 machine. Even setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) didn't solve the problem.
Launching tmux with -u option did the trick (tmux -u)
From the tmux FAQ:
I use PuTTY and my tmux window pane separators are all qqqqqqqqq's!
PuTTY is using a character set translation that doesn't support ACS line
drawing. With a Unicode font, try setting PuTTY to use a different translation
on the Window -> Translation configuration page. For example, change UTF-8 to
ISO-8859-1 or CP437. It may also be necessary to adjust the way PuTTY treats
line drawing characters in the lower part of the same configuration page.
That being said, I use tmux 1.8 with PuTTY 0.62, "UTF-8 translation", "Unicode line drawing code points" and a remote locale of en_US.utf8 which works perfectly fine.
You probably have PuTTY configured to use Unicode without using a UTF-8 locale on your FreeBSD box, or the other way round (if I switch my remote locale to C without touching my PuTTY settings I get the behaviour that you describe).
In my case I could fix it by enabling a setting in PuTTY:
Window ->
Translation ->
Adjust how PuTTY handles line drawing characters ->
[X] Enable VT100 line drawing even in UTF-8 mode
This makes sense, since the "lqqqk" sequences are what VT100 line drawing looks like if it is not interpreted as such.
I had the same problem. The root reason was that the Linux system was using locale "POSIX".
The issue is resolved by:
# show system locale
locale
# using utf-8 as system locale
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
# attach tmux
tmux a
When invoke vi in a session inside SCREEN, I always encounter error:
bash-3.2$ vi perf332.db2
ex: 0602-108 screen is not a recognized terminal type.
[Press return to continue]
[Using open mode]
After I explicitly export TERM=xterm or something, it works fine.
My SCREEN is running on a Linux server, and I SSH from there to a AIX server.
The default TERM variable for screen is TERM=screen. This is what its supposed to be.
You might consider putting something like this in your .bashrc to change the TERM variable to xterm when its screen.
if [[ $TERM = screen ]]; then
export TERM=xterm
fi
However I do not recommend doing this as this might confuse other application.
It seems vi does not know how to send commands to screen when the TERM variable is set to screen. The other way of getting around this would be to install vim which does understand how to communicate with screen.
Try putting shell -$SHELL into your ~/.screenrc file
I am trying to use rxvt on my cygwin w win XP but the terminal appears and disappears. What could be wrong? This is true for all except rxvt-native . I have tried a few commands found online but with no success. I include 2 I have tried:
start C:\cygwin\bin\rxvt.exe -sb -sl 3000 -fg gray -bg black -fn "Lucida Console-14" -e /bin/bash --login -i
.
path C:\cygwin\bin;%path%
ssh-agent rxvt -e bash --login -i
Another problem I am facing is trying to get vi to work in my cygwin bash shell. Setting term to xterm or vt100 does not work. Hitting enter, I see a string 78 or some other issue pops up. I have never modified my .inputrc.
My main issue was trying to get vi to work properly. I just found out that if I run
/etc/postinstall/terminfo.sh.done , I can now navigate properly in vi. The 78 (newline) M still appears but at least I can navigate in vi.
Feb 25 - This problem went away after a few windows updates. Would it make sense to ANSWER my question on the basis that this is longer reproducible?
Can't answer the first question, but have you tried invoking rxvt from its shortcut in the Cygwin folder of the start menu?
Regarding the second question, the TERM variable tells applications what terminal they're running in, so if you set it to 'xterm' while running in the Cygwin console (where normally TERM=cygwin), they'll be sending xterm control sequences that the Cygwin console doesn't understand. So basically: don't do that!
Btw, you might also be interested in Cygwin's mintty package, which is another terminal that doesn't need an X server. Installing it also creates a start menu shortcut in the Cygwin folder.
I would assume you need an X server running.
You could install Cygwin/X
One thing which may not have been clear was that the whole exercise was to get vi to work. vim did not work either at that time. But after some windows update, the problem went away. Closing it...