[RFC] Set the default locale to en_US.UTF-8

[Slawa Olhovchenkov]

On Sun, Jan 25, 2015 at 08:21:43PM +0100, Baptiste Daroussin wrote:

> On Sun, Jan 25, 2015 at 10:17:33PM +0300, Slawa Olhovchenkov wrote:
> > On Mon, Jan 26, 2015 at 05:59:51AM +1100, Peter Jeremy wrote:
> > 
> > > On 2015-Jan-25 18:50:00 +0300, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
> > > >On Sun, Jan 25, 2015 at 06:58:13AM -0800, Jordan Hubbard wrote:
> > > >> > On Jan 25, 2015, at 6:32 AM, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
> > > >> > 
> > > >> > NO! Please, NOT!
> > > >> > Not all bytestring allowed in UTF-8, as result -- unpedicable failed
> > > >> > execution of sed, grep, vi, ed and etc.
> > > 
> > > I switched to en_AU.UTF-8 about 5 years ago with relatively little pain
> > > (though I had very little non-ASCII text).
> > > 
> > > The downside of UTF-8 in that random non-ASCII bytestrings are unlikely to
> > > be valid UTF-8 and will therefore get rejected.  About the only time I get
> > > bitten by this is that my random password generator:
> > >   dd if=/dev/random bs=32 count=1 | tr -cd '!-~'
> > > will die with an "tr: Illegal byte sequence" and needs a "LC_ALL=C" to
> > > placate it.
> > 
> > Yes, I now remeber -- other case will be tr.
> > 
> > > >I am years use ru_RU.KOI8-R. Now I try use ru_RU.UTF8 and got some
> > > >issuse (on 10-STABLE). 9.x and OS may have dufferent version of
> > > >software and don't touch this.
> > > 
> > > Once you've started using any 8-bit locale, switching to UTF-8 (or any
> > > other 8-bit locale) will be a PITA because you need to re-encode everything.
> > > And, since it's very difficult to run with multiple locales, you need to
> > > do a complete sweep when you change locales.  If you are running into
> > > specific issues with incorrect handling of ru_RU.UTF8, that is a bug and
> > > you need to report it.
> > 
> > No, I don't have incorrect handling of ru_RU.UTF8 (for correct UTF8
> > files), I have trouble with processing non-utf files (like example
> > with tr)
> 
> That is why on my proposal also set LC_COLLATE=C which fixed the tr case for
> example

How customer can prdeict this?
Before this all work fine. After locale change somethink can be
broken. I am don't predict 'tr' failure. What broken next? What broken
in third-party? On already installed system, of couse. Running in
prodution many years.