Bash in gnome-terminal shows control characters as unsupported-unicode squares

[Quintin Beukes]

Binary package hint: gnome-terminal

When I upgraded to Karmic (clean install) I noticed bash echoes control characters using the hat notation (ex. ctrl+c shows as ^C). stty reported echoctl being set, so I tried to unset it. This helped, and pressing ctrl+c at a prompt cancels the prompt, shows a new one and nothing is echoed.

Though, when pressing ctrl+c while a program is running (ex. cat or ping), a unicode square is echoed like for unicode characters not supported by the selected font. I tried selecting many different encodings and fonts, though nothing seemed to help.

Futher, if inside this same shell I open a screen session, this behaviour is gone and everything works as intended, which is to have ctrl+c or ctrl+z have the desired effect with nothing echoed.

Finally, opening a bash session in xterm or tty[1-6] and disabling echoctl/ctrlecho using stty command, this cannot be reproduced. So it seems that only an plain bash session in gnome-terminal does this.

To see a screenshot, view the attached PNG.
Basically what happens there is
1. 2 ctrl+c presses at the prompt.
2. Then 1 ctrl+c during cat
3. Then 1 ctrl+z during cat
4. Bring cat back to the foreground and press ctrl+c again
THEN disable echoctl
5. Repeat the process - where you can now see instead of hat notation, the prompt presses are fine, but the in-program presses echo unicode squares.

Very frustrating.

ProblemType: Bug
Architecture: i386
Date: Wed Dec 30 12:40:10 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/gnome-terminal
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
NonfreeKernelModules: fglrx
Package: gnome-terminal 2.28.1-0ubuntu1
ProcEnviron:
 LANGUAGE=en_US.UTF-8
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: gnome-terminal
Uname: Linux 2.6.31-16-generic i686

[Pedro Villavicencio (pedro)]

do you get the same with terminator(terminal emulator) or xterm?

[Quintin Beukes (quintin)]

Can be reproduced with:
gnome-terminal: YES
terminator: YES
xterm: NO
tty[1-6]: NO

I attached another screenshot showing a ctrl+c in "/bin/cat" for gnome-terminal, terminator and xterm.

[Quintin Beukes (quintin)]

An easy way to reproduce this is to just do:
printf "\003\n\x1A\n"

This shows than when receiving these characters, gnome-terminal tries to print them, instead of ignoring them.

When doing: printf "##\003##\n", gnome-terminal (and thus also terminator), will print 2 hash characters, then the unicode square, then another hash covering the 2nd half of the unicode square (because the square is seen as a single character, though it takes up the space for 2), then another hash.

Xterm, screen and tty (TERM==linux) the same command will just print 4 hash characters.

If this might help, I have to mention again that running a screen session in gnome-terminal it works as intended. I don't know if this is the doing of ncurses or a terminfo configuration, or the separate utf8 encodings installed with screen.

[Douglas Bagnall (douglasbagnall)]

The annoying thing for me is not that these characters are represented, but that they ignore the character grid. If I run,

   for x in `seq 1 31`;do echo -e $x-\\x$(printf %x $x)=;done

it should print the character code, followed by a minus, followed by a representation of the character code, followed by an equals sign -- except when the character code tells the cursor to jump around or delete stuff.

On the linux console, and in plain old xterm, the non-moving characters print are invisible and take up no space.

In xfce4-terminal, they print as little squares but stay within their assigned box.

In gnome terminal, as in the attached picture, they encroach over the following character, so that you can't read it.

This is annoying, because it means you can't look at files that e.g. use the field separator codes (28-31) as field separators.