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. ** Attachment added: "Image showing many control characters misbehaving" https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/501601/+attachment/4134902/+files/gnome-terminal.png -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/501601 Title: Bash in gnome-terminal shows control characters as unsupported-unicode squares Status in “gnome-terminal” package in Ubuntu: Incomplete Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/501601/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
