Ubuntu
util-linux package

  1. Bug #273189
  2. Comment #3

Comment 3 for bug 273189

Revision history for this message
Colin Watson (cjwatson) wrote : Re: non-ascii layout/encoding problems at "login" line

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.