From owner-freebsd-current@FreeBSD.ORG Tue Jul 8 13:57:15 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB4C1065683; Tue, 8 Jul 2008 13:57:15 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AE8F88FC20; Tue, 8 Jul 2008 13:57:13 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4873723D.7040501@FreeBSD.org> Date: Tue, 08 Jul 2008 15:57:17 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= 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> In-Reply-To: <48736FB7.8070900@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2008 13:57:15 -0000 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