#2054: Grep-2.5.3 ------------------------------------------+--------------------------------- Reporter: [EMAIL PROTECTED] | Owner: [email protected] Type: enhancement | Status: new Priority: normal | Milestone: 7.0 Component: Book | Version: SVN Severity: normal | Resolution: Keywords: | ------------------------------------------+--------------------------------- Comment (by [EMAIL PROTECTED]):
Replying to [comment:1 [EMAIL PROTECTED]: > There are 2-3 test suite failures in this Grep release. I searched for a fix and found none. Grep-cvs has the same failures. It may be why no distros have picked up this release. Mine only reports 3 of 14 tests failed, but the first one (foad1.sh) is a series of tests with -i and -o, and many with --color=always which mixes escape sequences into the results in the log and is pretty much unreadable. Tentatively, I think -i (ignore case) and -o (show only the match) aren't working together (-i works, -i and -o gives no output, at least if the match is in the other case), and colour highlighting of the match doesn't seem to be working if it's in the other case. The two tests after that also fail and looking at the results I don't have a clue what is going on in those two. Fortunately, google knows a little about this - [http://www.diy- linux.org/pipermail/diy-linux-dev/2007-August/001066.html] shows much the same (in Greg's case fmbtest.sh was skipped, in my case it had failures. He points to [http://lists.gnu.org/archive/html/bug- grep/2006-03/msg00004.html] which implies these are long-standing new catch-all tests ready for when they can fix the problems. [https://savannah.gnu.org/bugs/?18666] seems to be similar I think I've seen these failures on other architectures with my most recent clfs builds (never got around to doing more than noting there were 2 or 3 failures), which leads me to guess they aren't critical for normal use. Some of the tests in foad1.sh seem to be in UTF-8, but they display as garbage in my log, and I can't type non-ascii in my chroot rxvt-unicode session. Curiously, when I try executing the program from outside chroot, and passing it a string containing UTF-8 cyrillic and accented latin letters as well as the ascii letters for which I'm searching, the new version seems to work correctly for -i -o --color=always. Ah, outside chroot I'm in en_GB.UTF-8. Unfortunately, setting LC_ALL in chroot doesn't make my simplified manual test succeed. Looking at foad1.sh within chroot, there are many other tests which presumably do succeed, it's only the combination of -i with -o, and some or all of the UTF-8 case-insensitive matching that are failing (my log is garbling ALL of the UTF-8 it shows, so I can't recognise what it reports). Although I can't type non-ascii in that session, I can read it in files even in the C locale, but I can't read the output from the cs_CZ.UTF-8 tests - maybe the highlighting for --color=auto is trashing it. Seems to fail similarly on the host system. -- Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2054#comment:6> LFS Trac <http://wiki.linuxfromscratch.org/lfs/> Linux From Scratch: Your Distro, Your Rules. -- http://linuxfromscratch.org/mailman/listinfo/lfs-book FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
