Date: Tue, 08 Jul 2008 15:57:17 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= <gabor@FreeBSD.org> Cc: hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] Message-ID: <4873723D.7040501@FreeBSD.org> In-Reply-To: <48736FB7.8070900@FreeBSD.org> References: <20080617004647.GA16546@nagual.pp.ru> <48576610.9080808@FreeBSD.org> <48577510.4020007@aueb.gr> <48577BD2.4070205@bluemedia.pl> <20080617102900.GA46479@nagual.pp.ru> <485798C4.2050605@FreeBSD.org> <20080618055851.GA85018@nagual.pp.ru> <86zlpjduew.fsf@ds4.des.no> <48598C6D.4040102@FreeBSD.org> <48727747.7070509@FreeBSD.org> <20080707201447.GA37354@nagual.pp.ru> <48727F14.6090507@FreeBSD.org> <48728301.5070403@FreeBSD.org> <487294AB.3000609@FreeBSD.org> <48736FB7.8070900@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gábor Kövesdán wrote: > >>> Well, it seems you have missed the first nits of the discussion. GNU >>> grep has some regression test, which doesn't pass completely itself >>> either. :) I've mentioned here that I used those tests to find out >>> what incompatible options are there. Unfortunately, I have to say >>> that BSD grep won't pass all of those, because GNU allows some >>> non-standard regexes, which are rejected by our libc-regex library, >>> like for example (a|) is not standard because it has an empty >>> subexpression. First, I tried to pre-edit such expression in the >>> code. It was ugly enough but I thought: "Ok, this code is pretty >>> ugly, but compatibility is important, maybe we can later revise >>> and/or change our regexp library and get rid of these snippets." >>> Later, when Andrey pointed it out, I realized that my workarounds >>> adressed those incompatibilities but didn't work completely, they >>> broke compatibility at other places, thus I just removed them, >>> because it was not that easy to fix. The version that I sent you for >>> the portbuild test, doesn't have those workarounds. The regression >>> test helped though to fix other compatibility issues, like return >>> values. All of these trivial things are supposed to be compatible >>> now, the only exceptions are the non-standard regexes. That's why I'm >>> so curious about the results. If they are inacceptable, we can try to >>> build BSD grep with the GNU regexp lib (it's in the tree, as Pedro F. >>> Giffuni pointed it out). It doesn't work by just linking with that >>> library, so it will need more work and investigation then, not >>> speaking about that GNU regex should go one day... >> >> OK, yes I did miss the start of the thread, but I was trying to >> suggest that grep doesn't seem to be functional enough yet and this is >> a way to work on identifying what needs to be fixed. > Could you please send me some logs of ports which build with GNU grep > but not with BSD grep? That would help me to identify the problems and > find out if those problems come from non-standard regexes or what's > happening here? No, because every port build fails because egrep -v is failing to work properly in the management scripts :) I sent you mail about this already. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4873723D.7040501>