Weird characters in ncurces applications in screen over ssh

[PM17E5]

I use pork which is an AIM client on a headless box over ssh. I'm not sure if it's ssh, lack of character support on the server, or something with pork but instead of seeing a line the way it would usually be drawn in ncurces, I see ââââââââââââââââââââââââââââ. It gets pretty annoying looking at everything made out of garbage. Does anyone have any ideas where I should begin to look to diagnose this problem?

Oh and another thing, I don't have this same issue on another box, things are displayed as they should be. The emerge --info of the headless box is:

[wuzzerd]

Try setting the value of the TERM variable in the environment of the remote connection to something compatible with your local terminal.

[PM17E5]

How would I go about doing that?

[Mike Hunt]

I think you could set it in the .bashrc file of the remote box's user account; e.g.

TERM=linux

Run set | grep TERM on your local box.

[PM17E5]

Aha, thank you for that tip, I'm starting to get somewhere.

It appears that if I run the ncurces application in plain console over ssh then everything is fine. However when I run it in screen over ssh that is when it starts to draw those weird characters instead of lines, at least in that particular application that I've tried. I tried this in a local console in screen and it drew everything fine. Also I remember it wasn't always like this on the remote machine. I checked the variable for TERM and both local and remote machine showed "xterm". However when I check that variable inside a screen session over ssh, the output is very strange:

[Mike Hunt]

I know your remote box is headless, but are you running X sessions at both ends? And if so what kind of terminals are running?

I'm asking because your TERM=xterm.

[PM17E5]

Nope, I have no xorg on the headless box, but I'm using plain old xterm on my home machine. You just made me think of trying something else though, I logged in without xorg on plain console to the box and connected to the screen and everything was being displayed just fine. So the issue must be my box? Hmm.

On a gui-less machine, what should the xterm TERM value typically be?

[Mike Hunt]

Most likely TERM=linux

[PM17E5]

Do you have any ideas on my most recent findings? And what I should do on my local box?

[Mike Hunt]

You could try a different type of terminal on your local box: rxvt-unicode for example, see how that goes.

[PM17E5]

I don't like all those bloated terminals, and it didn't always used to do this. I don't get why it's doing it now. Maybe I'm missing some sort of encoding?

[PM17E5]

Anyone?

[Buddie]

Have you set your term in your .screenrc?
I had a similar problem a while ago and setting 'term rxvt-256color' in my .screenrc sorted it out.

[PM17E5]

Tried it, doesn't do a thing.

[animous]

Raising this thread from the dead with a solution.. I ran into the same problem today. Using putty, running mucous (museekd ncurses client) inside a screen would print a bunch of garbage ââââââââââââââââââââââââââââ instead of lines. The display was perfect when not running from inside a screen.

After lots of googling, fiddling with TERM, .screenrc and other stuff, I stumbled upon a solution myself..

All you need to do is change ISO-8859-1 to UTF-8 in putty. Do this by going to Session settings/Window/Translation/Received data -> select UTF-8.

Hope this helps someone 'cause I know it was driving me nuts.

[tomk]

To get screen to display in UTF-8 you should use the -U option.
_________________
Search | Read | Answer | Report | Strip

[Bapabooiee]

I've also been experiencing this issue; thanks for the fix.

Also, if you want Screen to use UTF-8 without having to specify the -U switch every time, just add the line "defutf8 on" into your ~/.screenrc file: