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 to work. 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 produces: # Configuration file for the color ls utility # You can copy this file to .dir_colors in your $HOME directory to override # COLOR needs one of these arguments: 'tty' colorizes output to ttys, but not # pipes. 'all' adds color characters to all output. 'none' shuts colorization COLOR tty # Below, there should be one TERM entry for each termtype that is colorizable TERM xterm-color TERM color-xterm TERM color_xterm # 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 string. 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 were ok. 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): grep-2.5.1-36 How reproducible: 100%
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: ftp://people.redhat.com/twaugh/tmp/grep/ 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 Do: /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 E.
Created attachment 106950 [details] Heres
Fixed package is grep-2.5.1-40, which will appear in Fedora development tomorrow. In the mean time I'll put it here: ftp://people.redhat.com/twaugh/tmp/grep/ (Please report any future problems as separate bug reports; thanks.)