Bug 19973 - /etc/profile.d/lang.* assumes that locale "en_US" is exactly identical to locale "C"
Summary: /etc/profile.d/lang.* assumes that locale "en_US" is exactly identical to loc...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-28 23:14 UTC by Ronald Cole
Modified: 2014-03-17 02:17 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-05 21:12:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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.

Note You need to log in before you can comment on or make changes to this bug.