Bug 19973

Summary:	/etc/profile.d/lang.* assumes that locale "en_US" is exactly identical to locale "C"
Product:	[Retired] Red Hat Linux	Reporter:	Ronald Cole <ronald>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.2	CC:	i.wells, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-11-05 21:12:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ronald Cole 2000-10-28 23:14:29 UTC

Having been expertly argued in bug #19942 that such an assumption is
unwarranted, there are two bugs here:

1. /etc/profile.d/lang.* should not change locale "C" to locale "en_US",
   because they are not the same!

2. Whatever package created /etc/sysconfig/i18n ("rpm -qf" on that file
   does not associate it with any package), should not have set
   "LANG=en_US".  The GNU C Library Reference Manual clearly states that
   there are only two predefined locales: "C" and "POSIX", all others are
   vendor supplied extensions.  If a different locale is desired, then the
   administrator installs that and changes that file as a matter of system
   policy, or a user creates his own $HOME/.i18n file.  At the very least,
   that value should be queried for as part of the system install/update.

These bugs are also present in RH7.0.

Comment 1 Bill Nottingham 2000-10-29 04:05:37 UTC

Hm, probably correct on the first point. We'll look into
changing that.

As for what sets that locale, it's the very first question
in the installer.

Comment 2 Ronald Cole 2000-10-30 21:22:43 UTC

Then it's an unfortunate oversight that standard locales, "C" and "POSIX", are
notably missing from the list of locales given to select from in the first
question asked by the installer.  This seems to me to be an area of the
installer that is not well thought out.  IMO, the languages used for the install
and for the locale shouldn't be assumed to be the same.  If I ran the world, I
would split this question into two parts for the next release: language
presented to the installer, and choice of system locale.

Comment 3 Need Real Name 2000-10-31 14:28:24 UTC

Please remember that 'locale' and 'language' aren't the same thing, too.  Just 
because I want my programs to talk to me in en_GB doesn't mean to say I 
want 'sort' to do strange things...

Comment 4 Ronald Cole 2000-11-05 21:12:42 UTC

Well, yes, as I would expect, too.  The ISO C standard says that all programs 
will get "C" locale unless otherwise arranged.  It appears, however, that some 
pholx "who know better than us" decided that sort shouldn't have an option for 
arranging otherwise, rather that sort should de-facto use the environment 
locale and that you should have to change the environment if you want 
differently.  I haven't researched where this boneheadedness originated so I 
don't know whether to pin the blame on POSIX or GNU.

So, I agree with you.  Sort should talk to me in my chosen locale, but should 
sort in "C" locale unless I explicitly give it an option on the command line to 
do otherwise.  Since I speak Engish as my first language, I'm willing to 
remove /etc/sysconfig/i18n after an install as a workaround for this "travasty".

Comment 5 Bill Nottingham 2000-11-13 05:55:07 UTC

The change (not converting 'C' to 'en_US' was made in 5.50. 5.51
should currently be in rawhide.