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 stream”. 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 [email protected] for what they think about it, and never got an answer. Samuel -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
