4

This is quite a hard problem to explain, when connecting to one of my servers using the bash shell, under any user the line wrapping is broken and has all sorts of problems. Once of which I detail in screenshots below: enter image description here

Part2

Part3

Part4

Other problems I experience include nano getting very confused about which line and or letter I am on, as shown by typing the same message into nano:

Nano is broken

These problems only occur when connecting as I previously mentioned to one of my servers which runs CentOs. Do you know why this is occurring and what I can do to fix it? On other servers the message works fine!

Other server working

Thanks for your time,

Output of requested commands:

Server that doesn't work properly: Not Working Sever

Working server:

Server that works

Could it perhaps be the custom prompt on the non working server? In .bashrc

PS1='\e[1;32m\u@\h\e[m:\e[1;34m\w\e[m$ '

Commenting this out appeared to resolve the problem.

Google says line wrapping errors can occur if you don't conform to these rules

use the \[ escape to begin a sequence of non-printing characters,
and the \] escape to signal the end of such a sequence

I am not sure where this would fit in on my prompt?

Pez Cuckow
  • 525
  • 3
  • 8
  • 22

3 Answers3

5

The custom prompt is the issue (from your comments).

PS1='\e[1;32m\u@\h\e[m:\e[1;34m\w\e[m$ '

It's either sending a control sequence your terminal doesn't understand or it's not well formed.

You could try this,

PS1='\[\e[1;32m\]\u@\h\[\e[m\]:\[\e[1;34m\]\w\[\e[m\]$ '
EightBitTony
  • 9,311
  • 1
  • 34
  • 46
  • FYI - the *reason* it solved your problem, is the changes tell BASH which of your prompt characters take up no space (it needs to know how long your prompt is in displayed characters - ANSI escapes take zero space) – cnd Nov 15 '16 at 00:11
2

This is almost certainly a difference of opinion between your terminal emulator and running system regarding terminal capabilities. If, as you say, it only happens on certain machines (or only over SSH), compare the value of the TERM environment variable between working and non-working systems, and attempt to set TERM appropriately on the system that isn't working.

This may not work, depending on how old the terminfo database is on the system that isn't working; it's possible that you'll need to upgrade that system, or at the very least find another TERM value that works for you and that the remote system knows about.

womble
  • 96,255
  • 29
  • 175
  • 230
  • I believe the server has Centos5 and it kept 100% update through YUM and custombuild so I don't imagine it is something being out of date, the only thing I can think of is a miss configuration somewhere. – Pez Cuckow Aug 22 '11 at 11:50
  • 1
    No, CentOS is *guaranteed* to be out of date with regard to the current state of the art. They don't upgrade things to the latest versions, they only apply security bugfixes. Terminfo databases on old CentOS/RHEL releases are always a pain to deal with. – womble Aug 22 '11 at 11:51
  • 1
    I haven't had these issues with centOS before using nano, but then again I don't use Lion and their updated version of terminal, which as I have heard is terrible (256 color support aside). Like Womble said this may be as simple as terminal just doesn't understand how its supposed to be reading back the bits from the centOS box. Have you tried any other editors to see if you have the same problem (vi, vim, emacs, pico?) Does it only happen with this centOS box? – Wilshire Aug 22 '11 at 12:10
2

I was facing the same problem. I went into Terminal's "Preferences" in Lion (latest OSX 10.7.3) and then into:

Settings --> Advanced --> "Declare terminal as"

And chose "xterm" instead of the original V100.

Problem solved.

(This is because I love my custom prompts etc..)

PKHunter
  • 209
  • 2
  • 3
  • 11