[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: utf



On Mon, Apr 02, 2018 at 07:43:23AM +0000, Curt wrote:
> The thought provoked in my neurological matter was why there are other
> locales at all if UTF8 (the locale of this here .homie machine, BTW) is
> "vastly superior for all purposes".
> 
> That leaves no purposes remaining whatsoever for the myriad other
> locales.
> 
> If this is indeed so, let's get rid of them, then, (the superfluous
> locales) thus lightening our loads in computer life. 
> 
> Or are there legacy, corner, arcane purposes for these locales, of which
> the hoi polloi (of which I am a card-carrying member) has not to concern
> itself? 

Yes, there are other computer systems on the planet, and some of them
still use various single-byte character sets (ISO 8859-* or WIN1252
or similar).

In heterogeneous environments, it is often important for a Debian server
to support multiple locales, to fit the needs of legacy client systems.

For example, if you're sitting at a legacy Unix system which uses the
ISO 8859-1 character set, and you ssh to a Debian system that hard-codes
"LANG=en_US.UTF-8" in /etc/default/locale , this will clobber the locale
variables that are sent by the ssh client.  Then, commands like "man"
will generate output containing UTF-8 characters, which will seriously
mess up the display on an ISO 8859-1 terminal emulator.

(Why "man", or groff or whatever, feels the need to generate non-ASCII
characters is beyond me.)

This is why <https://wiki.debian.org/Locale> has complicated instructions
that DO NOT force an override LANG=... in /etc/default/locale (which is
destructive and wrong), but instead use fallback values in /etc/profile
and /etc/csh/login.d/lang .

This is also why I was probing login.conf and pam_env.conf for the ability
to support fallback/default environment variable values in that other
thread last week.  (Sadly, there is still no known alternative to the
login-shell-dependent hackery.)


Reply to: