[Pkg-shadow-devel] Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8

Samuel Thibault sthibault at debian.org
Thu Mar 25 13:22:51 UTC 2010

Nicolas François, le Tue 23 Mar 2010 23:59:29 +0100, a écrit :
> Is it an issue to set the utf8 flag too often?
> (does it break something?,

It has the converse effect as forgetting it, cf the original bug report:

“ATM, if one runs cat from a VT with a UTF-8 locale, type a non-ascii
character, backspace, enter, the first byte of the utf-8 encoding
non-ascii will remain in the stream.”

The converse would be “with utf8 spuriously set, if one runs cat
from a VT with a non-UTF-8 locale, type a character, then a non-ascii
character, backspace, enter, the first character is dropped from the

That's not so much a big deal (that is why nobody bothered to fix the
reported bug up to now), but it's still bogus (the other way round).

> does it affect performances?)

The performance hit is very tiny: just a couple of additional tests in
the kernel.

> Also, can you elaborate on your solution. Who would configure what and how?

I don't know enough the pam stack to know whether my solution is even
feasible.  My point is that it there are at least two cases that need to
be considered:

- getty/login on a VT.
- getty/login on a serial port.

Both could be independently using utf-8 or not.

In the first case, getty could use ioctl(KDGKBMODE) to know whether the
VT keyboard is configured in UTF-8 mode or not, and set the IUTF8 flag
appropriately. That brings Linux-specific code to getty which for now
was quite OS-independent, but well.

In the second case, however, getty can not use ioctl(KDGKBMODE), since
only the other end of the serial cable knows whether it's using utf-8 or
not. The locale setting, however, has very probably been properly set
up by the user or the administrator and could be used as the source of
information for setting UTF-8 mode or not.

That is why I thought about setting it at the login/pam level, where I
believed the locale information is available, which captures both cases.

I had asked util-linux at packages.debian.org for what they think about it,
and never got an answer.


More information about the Pkg-shadow-devel mailing list