From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827
Description of problem:
If I install Red Hat Linux 8.0 and select British English as my
language in anaconda, the environmental variable LANG gets set
to en_GB.UTF-8 (in 7.2 it was set to just en_GB). However, the
directory /usr/share/locale only contains an en_GB directory and
no en_GB.UTF-8 directory, which breaks grep (and no doubt other
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install RH 8.0, selecting British English as a language when
2. Run this command (grep is undoubtedly not the only broken app,
but it's the easiest to demo):
echo "hello" | grep "[A-Z]"
Actual Results: The command outputs the string "hello".
Expected Results: It should NOT output anything (upper case A-Z are not present
lower case string "hello"). I can imagine this would break a heck
of scripts on the system...
British English environments set LANG to en_GB.UTF-8 in RH 8.0 -
if you set it to en_GB instead, the grep example works correctly
(and this is the easiest workaround IMHO for this bug - although
you could soft-link en_GB.UTF-8 to en_GB in /usr/share/locale I
guess, but that feels less "correct").
Basically, Red Hat 8.0 omits to install an appropriate unicode
directory for British English, namely /usr/share/locale/en_GB.UTF-8.
One additional point here - Mandrake 9.0 *does* have that unicode
directory for British English, so it appears that RH 8.0 is indeed
BTW, I think some of Perl's XML modules in RH 8.0 also suffer
in a British English unicode environment, but I don't have the
full details to hand. Oh and apologies for putting in the grep component,
but I couldn't see an "internationalisation" component that was obvious
(this is a cross-app problem).
You forgot to use 'LANG=C' if you want POSIX locale character range matching.
The behaviour you see is correct for the en_GB locale.