Bug 91403

Description of problem:
See description of bug 43762 for a more agressive (but accurate) version of this
bug.

Version-Release number of selected component (if applicable):
2.3.11-1.9.0

How reproducible:
Always

Steps to Reproduce:
In the above-mentioned bug, teg states that: 'en_US is "C", with
working character order and 8 bit characters.'  This should say, 'with
*different* character order'.  If xinetd is going to provide a default, it
should provide the default that makes most sense - that is, nothing.  Every time
xinetd is upgraded, i have to edit /etc/rc.d/init.d/xinetd to restore the
default behaviour.  An extract follows:

    # Need to get rid of localization for external services - 
    # it doesn't make much sense to have i18n on the server side here

    LANG=en_US
    LC_TIME=en_US
    LC_ALL=en_US
    LC_MESSAGES=en_US
    LC_NUMERIC=en_US
    LC_MONETARY=en_US
    LC_COLLATE=en_US
    export LANG LC_TIME LC_ALL LC_MESSAGES LC_NUMERIC LC_MONETARY LC_COLLATE
The comment is not an accurate reflection of the code - en_US is just as much a
localization as any other.  If we were indeed getting rid of localization, the
above should read:
    unset LANG LC_TIME LC_ALL LC_MESSAGES LC_NUMERIC LC_MONETARY LC_COLLATE

Actual results:
/tmp $ mkdir a
/tmp $ cd a
/tmp/a $ touch A b C d E f G
/tmp/a $ LANG=en_US ls 
.  ..  A  b  C  d  E  f  G
/tmp/a $ LANG=C ls 
.  ..  A  C  E  G  b  d  f
This shows that LANG=en_US does not achieve the same result as LANG=C.

Expected results:
The same as it was before: no LANG setting in programs started from xinetd,
except what is set by themselves.  This allows programs which need localization
to sensibly test whether it is in place already or not.

Additional info:
At the very least, the comment in the xinetd startup script should be corrected
to state that we are using Red Hat's default choice for localization rather than
saying we are getting rid of it, and bug 43762 should be updated to "WONTFIX"
rather than "NOTABUG".