CLI lines wrapping overwrites in rxvt
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 |
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))
|
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 |
Quote:
|
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..
|
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?).
|
Quote:
|
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:
|
I'm afraid I experienced the line wrapping problem over the years in several versions of Slack while having done no modifications to .bashrc
|
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 |
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?
|
Quote:
|
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):\ Code:
# Append any additional kernel parameters: |
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. |
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' Code:
# man fprintf | less 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) |
As per this post I solved this problem by adding the output generated by
Code:
infocmp -C rxvt-unicode |
All times are GMT -5. The time now is 02:39 AM. |