On Tue, Jun 07, 2005 at 10:28:37PM +0100, Roger Leigh wrote: > Tollef Fog Heen <[EMAIL PROTECTED]> writes: > > Eh? You can't change that around just like that, it will break in the > > cases where people ssh in from machines with latin1 locales for > > instance (and use the PassEnv feature of newer SSHs). > > IMHO if you want features like that to work, you should be fully > qualifying your locale.
en_GB.ISO-8859-1 doesn't exist unless you go to the effort of defining it yourself - it's not in /usr/share/i18n/SUPPORTED. (Yes, in this case there happens to be an ISO-8859-15 equivalent, but that's not the case everywhere.) I'm fairly sure I remember glibc upstream vowing never to change the meaning of existing locales. Certainly this post from a locale hacker well-known in these parts comes to mind: http://lists.debian.org/debian-i18n/2004/10/msg00075.html > I've used UTF-8 default locales for several years now, i.e. > [/etc/locale.gen] > en_GB UTF-8 OpenSSH's SendEnv is a useful feature when applied to locales; it works for many people and fixes an old bug. I'd hate to break it just as it's started to work. > > To me, it looks like you can't ever change the charset of a locale > > once it is created. > > I don't agree. For the last three years, I've created them the "new > way", in contradiction to the default. Nowhere is it defined what the > existing unqualified locale names mean, save in the defaults, /usr/share/i18n/SUPPORTED is a little more than "the defaults", I think. It's at least standard across systems that use glibc (in that you may get additional entries, but you won't get different entries). This makes up sufficiently many systems to make me pay attention. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
