On Thu, 13 Aug 2009 14:02:45 +0200 Samuel Thibault <sthiba...@debian.org> wrote:
> Did you usually use a UTF-8 locale or a latin1 locale before? It may > be that setupcon doesn't properly detect whether you're using a > unicode console or not. This is configured > in /etc/default/console-setup, maybe the upgrade path didn't work for > you. > > Harald Braumann, le Thu 13 Aug 2009 13:31:51 +0200, a écrit : > > It is completely beyond me how setting an environment variable can > > influence keyboard/console output. > > It can in that readline uses it to know how to process characters. Ah, alright. At least one mystery solved. > > > It also makes it impossible for different users to use different > > locale settings. > > They at least need to use either 8bit locales or UTF-8 locales, > according to the /etc/default/console-setup CHARMAP's parameter. The > POSIX locale can be both. Of course, don't expect to be able to type > non-ascii characters at the shell of a POSIX locale. Contrary to what I believed, I could have set LC_CTYPE to POSIX instead of ISO-8859-1 (small bug in .profile). With the combination of LC_CTYPE=POSIX and CHARMAP=ISO-8859-15 I can reproduce the weird behaviour. However, this very same combination worked before the upgrade. But I've also upgraded bash and libreadline. So the changed behaviour might very well be due to changes in those packages or a combination of changes in those and in console-setup. While it would be interesting to know how this problem came to be, I think I just set LC_CTYPE to utf8 in /etc/environment and leave it at that. My previous experiences with digging into the details of keyboard and font problems was, that you can invest days and days... Cheers, harry PS: I think you can close that bug.
signature.asc
Description: PGP signature
