Red Hat Bugzilla – Bug 138558
grep-2.5.1-36 thoroughly broken in UTF-8 environments
Last modified: 2007-11-30 17:10:54 EST
Description of problem:
With an installation of grep-2.5.1-36 a machine become barely
useable. In particular it was rather hard to bring up an network.
A clue was provided by this detail that colouring in 'ls' stopped
In /etc/profile.d/colorls.sh there is the following test
if ! egrep -qi "^COLOR.*none" $COLORS ... ; then
Running that like this
LANG="en_CA.UTF-8" egrep -i "^COLOR.*none" /etc/DIR_COLORS
# Configuration file for the color ls utility
# You can copy this file to .dir_colors in your $HOME directory to
# COLOR needs one of these arguments: 'tty' colorizes output to ttys,
# pipes. 'all' adds color characters to all output. 'none' shuts
# Below, there should be one TERM entry for each termtype that is
# Below are the color init strings for the basic file types. A color init
# Text color codes:
# Background color codes:
# to colorize below. Put the extension, a space, and the color init
and, of course, the test "finds" the desired string. If one
will replace that with
LANG=C egrep -i "^COLOR.*none" /etc/DIR_COLORS
then there are no mathese. Actually it is enough to do LANG="en_CA".
I also tried with a number of other settings for LANG and every
time with ".UTF8" in it results were wrong and without that they
As a side effect trying to bring a network up with LANG="en_CA.UTF-8"
results only in messages
Missing config file ifcfg.
for every interface one tries to activate. Not sure what precisely
is responsible for that, as the whole setup is rather baroque,
but dropping ".UTF-8" makes networking operational again.
Because a file /etc/sysconfig/i18n is sources on many levels in
these procedures it needs to be edited before this is effective
in a startup.
The above was observed on x86_64. I do not have at this moment
i386 installation updated to that level.
Version-Release number of selected component (if applicable):
Confirmed. Thanks for the report. Correct behaviour can be regained
by setting GREP_USE_DFA=1 in the environment.
I have fixed this problem and built a new package, 2.5.1-37, to fix
the problem. It will be in tomorrow's rawhide. In the mean-time it
can be found here:
Please check to see if this fixes the problem for you. Thanks.
Indeed 2.5.1-37 from .../tmp/grep so far looks fine to me. At least
my network starts without "heroic efforts". :-)
Created attachment 106949 [details]
run grep -w magicword on this
grep-2.5.1-39 seems still badly broken on UTF-8
/bin/grep -w magicword foo
on the attached file ; I get the garbage foo.result (attached as well).
With GREP_USE_DFA=1, the problem goes away, but then we've got a
noticeable slowdown in matching (2x ; could be that it's the price to
pay...). See bug 121313
Created attachment 106950 [details]
Fixed package is grep-2.5.1-40, which will appear in Fedora development
tomorrow. In the mean time I'll put it here:
(Please report any future problems as separate bug reports; thanks.)