I'm seeing the same thing in bash, and it really seems to be at the application level. Here's an strace of it trying to read the £ sign:
read(0, "\302", 1) = 1 write(2, "\302", 1) = 1 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(0, "\243", 1) = 1 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(0, In other words, the console is feeding it the right characters, but it's dropping the second of the two bytes in the UTF-8 representation. Or ğ: read(0, "\304", 1) = 1 write(2, "\302", 1) = 1 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(0, "\237", 1) = 1 write(2, "\304\237", 2) = 2 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(0, Now, this is actually in X, not at the console, but bash at the console produced the exact same trace with the £ sign. dash doesn't exhibit quite the same effects, although it does fail to correctly backspace over UTF-8 characters. I know this isn't quite your original problem, but bash is a lot easier to debug interactively than login. I'm hoping that if I can see the systemic problem this way then login will be an easier target. -- non-ascii layout/encoding problems at "login" line https://bugs.launchpad.net/bugs/273189 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
