Re: And now for something completely different... etch!
-----BEGIN PGP SIGNED MESSAGE-----
Tollef Fog Heen <firstname.lastname@example.org> writes:
> * Roger Leigh
> | - When UTF-8 is the default locale, it shouldn't need a .UTF-8 suffix,
> | e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1 (the
> | opposite way round to the current situation which creates
> | en_GB.UTF-8 and en_GB [Latin-1]).
> 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 on its own has always meant "British
English", in whatever locale the system administrator set as the
default, and the same applies to all unqualified locales. Sure, ssh
might not work, but it /never has/, except by coincidence where two
systems had the same locale setup.
I've used UTF-8 default locales for several years now, i.e.
> 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, so there
are no guarantees here: they could have been set to /anything/.
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
-----END PGP SIGNATURE-----