CLI lines wrapping overwrites in rxvt

xj25vm · 06-30-2013, 01:06 PM

This has been happening for me over several years, on several Slackware version - but I just never found the time to investigate it.

When I use rxvt, after a while, lines don't seem to generate new line characters, so when reaching the end of the line (when typing a long command) - it jumps to the beginning of the line (on the same row) and starts overwriting characters. I can still press Enter, and the command will run correctly - but it makes it a pain to type and edit commands. Also, if I press the Up Arrow key to bring back the last command - it comes back on a single line - even if it would have originally spanned several lines - which makes it impossible to edit.

I haven't figured what triggers this behaviour - as it seems to start out of the blue randomly, after working in rxvt for a while. Closing rxvt down and re-opening it cures it.

I have tried to type "reset" and "clear" in rxvt, and it doesn't seem to fix things. I've found this post, which seems to describe the same behaviour - but it doesn't have any answers:

http://www.linuxmisc.com/6-linux-x/123025a75f4ee526.htm

perbh · 07-01-2013, 08:18 AM

Somewhere in my half-forgotten past I seem to recall encountering the same problem - which eventually led me to abandon rxvt. Maybe you could change to another 'terminal'? (xfce's terminal, kterminal - maybe even xterm (I can't remember if the latter had the same problem))

torimus · 07-01-2013, 02:19 PM

Are the dimensions of rxvt window changed before it starts happen ? For xterm running bash did helped to enable checkwinsize option in bash's init file like

Code:

[[ ${TERM,,} == *xterm* ]] && shopt -s checkwinsize

in $HOME/.bashrc

yars · 07-01-2013, 03:19 PM

Quote:

Originally Posted by perbh

Maybe you could change to another 'terminal'?

I have the same problem with xfce-terminal. I use it in maximized window mode, and I don't see the dependency between these behavior and the dimensions of window. Possibly this problem also exist in a text mode (on runlevel 3)?

D1ver · 07-01-2013, 04:38 PM

I've seen the same problem before, across xfce-term, xterm and konsole (across multiple slackware versions). I've never found a solution to stop it happening, but usually just resizing the window when it starts happening will make things normal again..

NonNonBa · 07-02-2013, 02:56 AM

Are you all using bash? I remember I've encountered this with xterm. I suspected it had something to do with the ANSI color sequences or the special variables I used in my prompt (aka PS1). Can't remember if it fixed the problem though (I now use a plain string as prompt and mksh as daily shell with rxvt-unicode... no problem for years, but where's the fix?).

xj25vm · 07-02-2013, 04:07 AM

Quote:

Originally Posted by yars

I have the same problem with xfce-terminal. I use it in maximized window mode, and I don't see the dependency between these behavior and the dimensions of window. Possibly this problem also exist in a text mode (on runlevel 3)?

I can't say that I've ever seen this problem running in non-X mode. But who knows

Jelloir · 08-04-2013, 12:39 AM

I recently encountered a similiar issue. It turned out to be something weird in my .bashrc PS1 variable.

Try giving yourself a vanilla PS1 (like PS1='$ ') and see of the behaviour disappears.

Quote from http://www.ibm.com/developerworks/li...tip-prompt/#h1

Quote:

In addition to this change, we need to surround all non-printing characters with special bash escape sequences, "\[" and "\]". These sequences will tell bash that the enclosed characters don't take up any space on the line, which will allow word-wrapping to continue to work properly. Without them, you'll end up with a nice-looking prompt that will mess up the screen if you happen to type in a command that approaches the extreme right of the terminal.

xj25vm · 08-04-2013, 01:47 AM

I'm afraid I experienced the line wrapping problem over the years in several versions of Slack while having done no modifications to .bashrc

jmccue · 08-04-2013, 05:54 AM

I have never noticed that issue and have been using rxvt for years. What termcap are you using ? But one of the first things I do after an install is to copy /etc/termcap-BSD to /etc/termcap.

John

xj25vm · 08-04-2013, 12:15 PM

I am using whatever termcap Slackware installs by default. Any particular reason why the change to the BSD termcap is required after a fresh Slack install?

jmccue · 08-04-2013, 05:15 PM

Quote:

Originally Posted by xj25vm

Any particular reason why the change to the BSD termcap is required after a fresh Slack install?

It is not "required", but I started using it years ago when I used Aterm with afterstep 1.8. termcap-BSD defines 'rxvt' which Aterm defaults to. I never got out of the habit of using the BSD version.

STDOUBT · 08-04-2013, 07:42 PM

I too, have learned to copy /etc/termcap-BSD to /etc/termcap.
Roughly, the difference as it was explained to me is that the termcap-BSD is more "feature-complete".
I use urxvt and have not seen that problem. I do have some other customizations which may affect the terminal's behavior, such as line 1985 in /etc/termcap (BSD version) to look like this:

Code:

rxvt-unicode-256color|rxvt-color|rxvt terminal emulator (X Window System):\

That helped get me out of ed mode though it might relate to the other problem as well. I also activated UTF-8 for virtual terminals in /etc/lilo

Code:

# Append any additional kernel parameters:
append=" vt.default_utf8=1"
HTH

ttk · 08-04-2013, 08:05 PM

I've noticed problems with programs like "less" under xterm for several years, too. The solution has always been to copy my old (pretty ancient now .. slackware 7.1, iirc) termcap to the new install's /etc/termcap. That might have originally been a BSD termcap.

It's been a familiar problem for so long that it never occurred to me to report it as a bug. A bit embarrassing, thinking about that.

ttk · 08-04-2013, 08:45 PM

For example, on a Slackware 14.0 system, with original-as-shipped /etc/termcap, with the following possibly-relevant environment variables:

Code:

# setenv | egrep 'TERM|LESS'
TERM=xterm
XTERM_SHELL=/bin/tcsh
TERMCAP=vs|xterm|xterm-color|vs100|xterm terminal emulator (X Window System):am:bs:km:co#153:li#61:ct=\E[3k:ue=\E[m:is=\E[m\E[?1l\E>:rs=\E[m\E[?1l\E>:eA=\E)0:as=^N:ae=^O:ac=aaffggjjkkllmmnnooqqssttuuvvwwxx:kI=\E[2~:kD=^?:kP=\E[5~:kN=\E[6~:k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k0=\E[21~:F1=\E[23~:F2=\E[24~:kh=\E[H:kH=\EOw:ks=:ke=:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ms:pt:xn:xo:it#8:RA=\E[?7l:SA=\E?7h:bl=^G:cr=^M:ta=^I:cm=\E[%i%d;%dH:le=^H:up=\E[A:do=\E[B:nd=\E[C:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:DO=\E[%dB:ho=\E[H:cl=\E[H\E[2J:ce=\E[K:cb=\E[1K:cd=\E[J:sf=\ED:sr=\EM:st=\EH:cs=\E[%i%d;%dr:sc=\E7:rc=\E8:ic=\E[@:IC=\E[%d@:al=\E[L:AL=\E[%dL:dc=\E[P:DC=\E[%dP:dl=\E[M:DL=\E[%dM:so=\E[7m:se=\E[m:us=\E[4m:mb=\E[5m:mh=\E[2m:md=\E[1m:mr=\E[7m:me=\E[m:ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:kb=\177:
XTERM_VERSION=X.Org 7.6.0(281)
XTERM_LOCALE=C
LESS=mqedX
LESSOPEN=|lesspipe.sh %s

Using an xterm, created via "xterm -display :0 -sb -sl 1024", I view multi-line text containing some blank and some non-blank lines (for this example I picked the output of "man fprintf", but a text file could have done just fine):

Code:

# man fprintf | less

So far, so good, (image) everything looks as it should.

Now I press "Enter" repeatedly, advancing the view one line at a time. When a non-blank line gets scrolled up from the bottom, it's fine, but when a blank line gets scrolled up from the bottom, it bears the text of less' progress indicator:

It should not do this. (image)