[SOLVED] terminal garbling/corruption in screen session

jamtat · 2013-01-29 16:58:40

I recently did a long-overdue system upgrade on one of my Arch systems (desktop) and am trying to sort out remaining issues. One of those arises when, using a urxvt terminal, I ssh into another machine on my LAN (which runs ubuntu 12.04) and re-attach to a screen session running there. This is how I've been doing e-mail (alpine runs on that machine) and reading news headlines (newsbeuter runs on that machine, and invokes elinks for reading full stories) for some years now. Prior to the upgrade, things were working pretty well: I was able to ssh into that machine, attach to the running screen session, and read mail and news. When I try that now, after the recent upgrade, though, there is sufficient corruption or garbling of the screen that it is almost unusable for certain tasks.

Now, I have had garbling/corruption issues in the past--though less severe, as I recall. If memory serves, the last time this cropped up I found that using urxvt to log in and re-attach to screen resolved pretty much all issues for me. But now the problem has resurfaced and is more severe than it had been in the past.

To make matters more confusing, I have a laptop with Arch installed on it as well. Using it, I can, using a urxvt terminal, ssh into said machine, re-attach to the screen session, and I see no garbling or corruption at all. So, that laptop works just as well the desktop did prior to my recent pacman -Syu.

The garbling/corruption manifests itself when I look at news articles using elinks as follows: frames are all off-kilter, and page formatting is pretty much haywire. Strange characters appear in place of what should be probably bullets, and artifacts are scattered around the pages. See a couple of screenshots below to get a better idea. I also see some corruption in Alpine when I look at mail, but what really bothers there is the fact that foreign language fonts are not displaying. I sometimes get e-mails with cyrillic lettering: I was able to read those fine previously. Now, however, all cyrillic letters are replaced by weird symbols.

So, how can I go about diagnosing and fixing this problem? Why would this problem occur on my desktop but not on my laptop? Input will be appreciated.

Thanks,
James

PS Screenshots of the garbled screen session can be seen at http://s2.postimage.org/588nv261l/screen_corrupt1.png and http://s7.postimage.org/vn2i3256z/screen_corrupt2.png

Last edited by jamtat (2013-01-31 19:02:01)

Torxed · 2013-01-29 17:00:35

screen -U -r <screen id/name>

When re-attaching to your screen session, passing the -U will enable unicode encoding of the output converting your scrambled characters into something the connected terminal will understand.
This is a common issue connecting from a MAC (OSX) -> Ubuntu -> screen -> irc via irssi (for instance).

This is just a temporary fix for you, hopefully.

Last edited by Torxed (2013-01-29 17:02:25)

jamtat · 2013-01-29 17:03:50

Thanks for your reply, Torxed. Adding the -U option doesn't seem to have any effect on the corruption/garbling.

James

Torxed · 2013-01-29 17:18:58

Sorry I couldn't be of more help, worth a shot tho

jasonwryan · 2013-01-29 17:19:32

It is likely an issue with the terminfo on the Ubuntu machine. Use `infocmp` on both machines to determine if their is a difference and, if so, scp your Arch one to the remote box and then install it with

# tic <termname>

jamtat · 2013-01-29 18:04:32

Thank you for your input, jasonwryan. I compared the output on the two machines and did note a few differences. So I scp'd /usr/share/terminfo/r/rxvt-256color to the same location on the ubuntu machine (having backed up the original). Now I'm trying to do the tic step, but there's obviously something I'm not understanding. I would think termname in this case would be rxvt-256color, but that doesn't work. Can you offer any further pointers on how to complete this step?

James

jamtat · 2013-01-29 18:50:19

Is this relevant: http://www.jbase.com/r5/knowledgebase/h … modify.htm ? Do I need to run

infocmp rxvt-256color > rxvt-256color.ti

on the file I scp'd over from my Arch machine? Then do

tic rxvt-256color.ti

to install it on the remote machine? Further pointers will be appreciated.

James

Last edited by jamtat (2013-01-29 20:36:42)

jamtat · 2013-01-30 02:50:25

I went ahead and tried this--or I should probably say I flailed away at it, since I really had very little understanding about what I was doing. Following directions found at the above site have not really helped, though. I finally determined that, if I copy my arch rxvt-256color file over the the ubuntu machine, then run

infocmp rxvt-256color > rxvt-256color.ti

on it, then, as user, run

tic rxvt-256color.ti

a new hidden directory appears in my home directory, namely .terminfo. Within that is the directory r and within it rxvt-256color. I assume this is the way a terminal definition is created for the user rather than system-wide. The presence of that file does affect the system: it causes urxvt terminals on the ubuntu machine to have some corruption in the screen session--not as bad, it's true, as the garbling/corruption I see when in a screen session via ssh--but still not very desirable.

So I think I've implemented the solution jasonwryan was proposing (feel free to disagree if you know more about this than I do). If so, I've found it inadequate. And, in any case, his explanation doesn't answer the question why I do not get this garbling/corruption in screen sessions when I ssh into the same ubuntu machine from my Arch laptop. Perhaps I need to consider copying its rxvt-256color file over to my Arch desktop and following the steps there that I've tried on the ubuntu machine? Or maybe just purging rxvt from the desktop, then re-installing it?

Oh, and by the way, is it correct that if I do

sudo tic rxvt-256color

the resulting rxvt-256color file gets copied under /usr/share/terminfo/r/, where it becomes effective system-wide? That makes sense, but I don't see a way to confirm that.

James

jasonwryan · 2013-01-30 03:08:38

jamtat wrote:

And, in any case, his explanation doesn't answer the question why I do not get this garbling/corruption in screen sessions when I ssh into the same ubuntu machine from my Arch laptop.

Compare all of the terminfo files...

And if the terminfo files are the same, make sure you aren't setting a $TERM in your shell initialization file (.bashrc or the like) on the Ubuntu box.

jamtat wrote:

Oh, and by the way, is it correct that if I do
sudo tic rxvt-256color
the resulting rxvt-256color file gets copied under /usr/share/terminfo/r/, where it becomes effective system-wide? That makes sense, but I don't see a way to confirm that.

Yes: you want to apply it system wide.

The first thing you should do is establish the term being used locally and remotely (both in and out of the screen session); just doing `echo $TERM` wil give you this. Then use infocmp to determine of there is any differences (as, apparently there is). infocmp should be used with the results of the echo command; ie.,

┌─[LocalMachine ~]
└─╼ echo $TERM
screen-256color
┌─[LocalMachine ~]
└─╼ infocmp screen-256color > screen-256
┌─[LocalMachine ~]
└─╼ vimdiff screen-256 screen-256-ubuntu
┌─[LocalMachine ~]
└─╼ scp screen-256 yourserver:
┌─[YourServer ~]
└─╼ sudo tic screen-256

jamtat · 2013-01-30 04:23:18

Thanks for the additional input, jasonwryan. I had checked the output of echo $TERM on both the Arch desktop and on the ubuntu machine previously, and both reported rxvt-256color. I've double checked that now, and that is what both still report. The laptop, which I just checked, reports the same. I had run that command from within the screen session and seen the same output previously. However, among my desperate thrashings to try and resolve this, I resorted to editing my .screenrc and changed the terminal type to screen-256color--that's what's reported from within screen now. I did not see any difference as a result of that change, though I could change it back to rxvt-256color to re-test.

I have no previous experience with diff but have run across indications that this is a good way to detect differences between files. The laptop and desktop rxvt-256color files seem not have have any differences when I feed them to diff, though the ubuntu file differs from both. Since I can't run vimdiff in a screen session (owing to the corruption issue), I'll have to run over to the ubuntu machine and try that now. I'll report back with results.

James

Last edited by jamtat (2013-01-30 04:29:07)

jasonwryan · 2013-01-30 07:23:50

The screen FAQ has some good tips on working with terminfo:
http://www4.cs.fau.de/~jnweiger/screen-faq.html

Or, you could just use a modern multiplexer like tmux...

jamtat · 2013-01-30 18:12:06

Well, I'm officially trapped in a nightmare. I tried tmux since I'm not a screen power user by any means and felt I would be unlikely to notice much difference between the two. But, using the Arch desktop to ssh into the ubuntu machine, I get pretty much the same terminal corruption with tmux as I was seeing with screen: elinks pages are strewn with all kinds of strange characters and frames are de-kiltered, while cyrillic fonts are rendered under Alpine with weird symbols. At the same time, the Arch laptop can ssh in to either the screen or the tmux session and everything looks great--no formatting or character-rendering issues at all.

I'll try and do some further investigating with vimdiff once I finish an unrelated project I need to complete.

James

jamtat · 2013-01-31 17:53:39

Now that I've finished my other, unrelated, project, I was able to get back to this today. I followed the steps more carefully this time, but that did not bring about a different result. I confirmed that the two rxvt-256color files on the desktop and laptop (both Arch) machines are the same by looking at them with vimdiff. The rxvt-256color file on the ubuntu machine (which I log into using ssh and though which I've been re-attaching to a screen session) differs from both the files on the desktop and laptop machines. But despite "installing" the Arch rxvt-256color file on the ubuntu machine (using tic, as jasonwryan suggested), the terminal corruption/garbling persists: that holds true whether I re-attach to a screen session or to a tmux session.

I should also mention that I tried tried ssh'ing in and re-attaching to screen/tmux sessions from a console on the desktop machine as well (ctrl - alt - F2). I see the same type of corruption/garbling, even from a console. Both console and rxvt terminal render fine--no corruption/garbling--when I try from the laptop.

Noting issues with the display of foreign fonts, I decided to do some checking regarding locales. I don't know whether this could be relevant, but here are some results that I found.

Issuing the command locale on the ubuntu machine returns the following:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

On the (Arch) laptop, the result of that command is:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

On the (Arch) desktop, however, I get the following:

LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=

Could the weird locale settings I'm seeing on the desktop be related to the issues I'm having?

Thanks,
James

jasonwryan · 2013-01-31 17:54:44

Yes.

jamtat · 2013-01-31 19:01:16

In accord with the Arch wiki entry on locales (https://wiki.archlinux.org/index.php/Locale), I created on the desktop the file /etc/locale.conf. There, I entered the content LANG="en_US.UTF-8", then rebooted the system (though I think only logging out, then in again, is required). Now when I run the command locale on that machine I get

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Furthermore, when I ssh into the ubuntu machine and re-attach to a screen session, the corruption/garbling I was seeing is now gone.

Thanks to all for input on this issue, which is now solved.

James

Arch Linux

#1 2013-01-29 16:58:40

[SOLVED] terminal garbling/corruption in screen session

#2 2013-01-29 17:00:35

Re: [SOLVED] terminal garbling/corruption in screen session

#3 2013-01-29 17:03:50

Re: [SOLVED] terminal garbling/corruption in screen session

#4 2013-01-29 17:18:58

Re: [SOLVED] terminal garbling/corruption in screen session

#5 2013-01-29 17:19:32

Re: [SOLVED] terminal garbling/corruption in screen session

#6 2013-01-29 18:04:32

Re: [SOLVED] terminal garbling/corruption in screen session

#7 2013-01-29 18:50:19

Re: [SOLVED] terminal garbling/corruption in screen session

#8 2013-01-30 02:50:25

Re: [SOLVED] terminal garbling/corruption in screen session

#9 2013-01-30 03:08:38

Re: [SOLVED] terminal garbling/corruption in screen session

#10 2013-01-30 04:23:18

Re: [SOLVED] terminal garbling/corruption in screen session

#11 2013-01-30 07:23:50

Re: [SOLVED] terminal garbling/corruption in screen session

#12 2013-01-30 18:12:06

Re: [SOLVED] terminal garbling/corruption in screen session

#13 2013-01-31 17:53:39

Re: [SOLVED] terminal garbling/corruption in screen session

#14 2013-01-31 17:54:44

Re: [SOLVED] terminal garbling/corruption in screen session

#15 2013-01-31 19:01:16

Re: [SOLVED] terminal garbling/corruption in screen session

Board footer