I had the same issue when running:
git clone https://github.com/jwiegley/git-scripts.git
cd git-scripts
perl git-forest
I used this as my test. Basically, you should get nice lines is you have utf8 set properly. If not you will get ugly boxes or characters.
The solution is that you need to set LC_ALL
to en_US.UTF-8
BEFORE you start a new screen session. I tired doing it after creating the screen session and had no luck.
Here are the step i followed to get this going:
1) Run locale
to view the current setup. I got this (which explains why i was having issues:
LANG=en_US.UTF-8
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=C
2) Before creating a new screen session, you need to redefine LC_ALL
to en_US.UTF-8
if you are using csh
shell
setenv LC_ALL en_US.UTF-8
if you are using bash
shell
export LC_ALL="en_US.UTF-8"
3) Verify LC_ALL
was set properly, by running locale
again:
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=en_US.UTF-8
4) Now run a new screen session and run the git-forest
test and you should see nice lines
Well, first I guess I would point out that pretty much all terminals these days are "virtual" in the sense you talk about... even if the terminal is at the other end of a bona fide serial port. I mean, the days of VT-100s, Wyse terminals and other "physical", "real" terminals are pretty much gone!
That aside, let's say you want to detect what kind of Unicode support your terminal has. You can do this by writing test characters to is and seeing what happens. (You can make an effort to erase the test characters after you've written then, but the user may still see them briefly, or erasing them might not work properly in the first place.)
The idea is to ask the terminal to tell you its cursor position, output a test character, ask the terminal again to tell you its position, and compare the two positions to see how far the terminal's cursor moved.
To ask the terminal for its position, see here. Essentially:
echo -e "\033[6n"; read -d R foo; echo -en "\nCurrent position: "; echo $foo | cut -d \[ -f 2
Try outputting "é". This character takes 2 bytes in UTF-8 but displays in only one column on the screen. If you detect that outputting "é" causes the cursor to move by 2 positions, then the terminal has no UTF-8 support at all and has probably output some kind of garbage. If the cursor didn't move at all, then then terminal is probably ASCII only. If it moved by 1 position, then congratulations, it can probably display French words.
Try outputing "あ". This character takes 3 bytes in UTF-8 but displays in only two columns on the screen. If the cursor moves by 0 or 3, bad news, similar to above. If it moves by 1, then it looks like the terminal supports UTF-8 but doesn't know about wide characters (in fixed-width fonts). If it moves by 2 columns, all is good.
I'm sure there are other probe characters that you could emit which would lead to useful information. I am not aware of a tool that does this automatically.
Best Answer
Something that runs inside GNU screen decided it was running in an xterm (or similar) instead and enabled Application Mouse mode. (Or something you run in that terminal before you attached to GNU screen, possibly even before ssh, which did not properly reset itself.) This is often the case if $TERM is not “screen” but e.g. “xterm” or “screen.xterm”. The latter is seen on Debian systems (and derivates) that have
ncurses-term
installed; try purging that package (on host and raspi).Otherwise,
reset
(as was already said) orprintf \\x033c
may help temporarily. Or, of course, the proper escape sequences to tell your terminal emulator to disable mouse mode.