Resuming screen with UTF8 enabled breaks character input

Question

Overview of UTF8 screen re-attachment issues.

Problem:

Creating a screen that uses UTF8 works perfectly until re-attaching said screen session.

Steps:

ssh remothost
screen -U -S ttytter
[detach screen]
[exit ssh]
xterm -class 'xterm-ttytter' -geometry 175x20 \
 -title 'ttytter' -e ssh -t remotehost "screen -dU -r ttytter"

Details

I am a really big fan of ttytter and have been using it for some time now. I have recently started using xterm vs xfce4-terminal/gnome-terminal as I find it is much cleaner. I am trying to use UTF8 for personal and professional reasons and I am still trying to work out a few bugs.

The initial attachment (creation) gives me UTF8 input that works like it should. $TERM is xterm-256colors while $LANG is en_US.UTF-8. This is also true once I re-attach the screen, although I am unable to use certain characters, such as backspace, which shows up as ^H.

It seems that the issue is specific to the command I am issuing to re-attach the screen. I am trying to figure out what it is that could be causing such an issue when I re-attach my UTF8 screen. I have tried -dr and -dU -r, both of which are failing to solve my problem. I have tried giving xterm the -u8 flag, giving me no change in behavior.

xterm -class 'xterm-ttytter' -geometry 175x20 \
-title 'ttytter' -e ssh -t remotehost "screen -dU -r ttytter"

The above causes problems.

ssh remotehost
screen -dU -r ttytter

The above works just fine.

Settings

.screenrc

defc1 off
defutf8 on
utf8 on

.Xdefaults

xterm*utf8: 1

.bashrc

export LANG=en_US.UTF-8

I will really appreciate any guidance on solving this issue.

• earthmeLon: The problem lies within me setting xterm's -class. $TERM is correct, but something about the class is breaking character input.

Answer 1

Solution

Different 'classes' load different configuration files from /etc/X11/app-default/. My problem was that my new xterm class did not have a matching configuration file.

# cd /etc/X11/app-default
# ln -s XTerm-color xterm-ttytter

The above will link XTerm-color's class settings for xterm-ttytter by creating a symbolic link. This way, any changes that are made to XTerm-color will automatically be applied to xterm-ttytter as well.

Credit goes to @Nei on Freenode/#xterm for explaining program classes for X11.

• earthmeLon: ttytter -readline is essential, as well.

Answer 2

The applications defaults files for xterm are designed to include XTerm-color using a different route. This resource

*customization: -color

would tell the X Toolkit library to load a resource file ending with "-color".

There are several app-defaults files installed for xterm. Looking at my /etc/X11/app-defaults, these are the main ones:

-rw-r--r-- 1 root 2400 Nov 27 2012 KOI8RXTerm
-rw-r--r-- 1 root 3609 Nov 27 2012 UXTerm
-rw-r--r-- 1 root 10112 Nov 27 2012 XTerm

and these are the color-customized ones:

-rw-r--r-- 1 root 6217 Nov 27 2012 KOI8RXTerm-color
-rw-r--r-- 1 root 6209 Nov 27 2012 UXTerm-color
-rw-r--r-- 1 root 6207 Nov 27 2012 XTerm-color

The XTerm and XTerm-color ones should require little explanation: the default class is XTerm, and the customization resource adds "-color". The others use different classes. You should be interested in the UXTerm class, since it sets this

 *VT100.utf8: 1

as well as setting up fonts useful with UTF-8. The uxterm script runs xterm using the UXTerm class, as well as ensuring that the locale environment variables are setup.

Further reading:

• 4. More X Configuration (The X Window User HOWTO)
• Debian Bug #167495: xterm: /etc/X11/app-defaults/XTerm-color shouldn't define unnecessary resources
• uxterm - X terminal emulator for Unicode (UTF-8) environments

Answer 3

I'm assuming you're getting garbled output, and if that's the case, try running the reset command, or maybe stty sane. This will treat the symptom, at least.