Re: And now for something completely different... etch!
On Tue, Jun 07, 2005 at 10:28:37PM +0100, Roger Leigh wrote:
> Tollef Fog Heen <tfheen@err.no> 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 [cjwatson@debian.org]
Reply to: