Date: Tue, 17 Jun 2008 20:51:57 +0200 From: Gabor Kovesdan <gabor@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: Diomidis Spinellis <dds@aueb.gr>, hackers@FreeBSD.org, current@FreeBSD.org, "Sean C. Farley" <scf@FreeBSD.org>, Max Khon <fjoe@samodelkin.net> Subject: Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo] Message-ID: <485807CD.1030601@FreeBSD.org> In-Reply-To: <4854BC29.3060507@FreeBSD.org> References: <485453F2.60507@FreeBSD.org> <4854BC29.3060507@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Barton escribió: > I use the following construct in portmaster, where pdb=/var/db/pkg, > origin is set to the origin of a given port, and ro_opd is usually > empty, but can be another origin directory or the same one. To > guarantee that you should get some kind of results you can test with > origin=devel/gettext. > > egrep -l "DEPORIGIN:($origin|$ro_opd)$" $pdb/*/+CONTENTS > > Obviously this works in portmaster with the gnu grep, but if ro_opd is > unset with the bsd grep I get: > > egrep: empty (sub)expression > I've looked at this and I have a patch with a workaround: http://kovesdan.org/patches/grep.dougb.diff Could you please try it if you have some time? I suppose that it will fix your case as it has fixed the 77th Spencer test of the GNU regression test suite, which comes with GNU grep. I'm afraid there isn't a better solution as this regression is coming from the different regex interpretations between the GNU regex library and our libc regex library. regex(3) says that the RE standard has some ambiguities and the particular implementation should make a decision how to handle these cases. Regards, Gábor P.S.: Thanks for the WITHOUT_GNU_GREP knob, I hope we will make use of it soon, I'm trying to eliminate the remaining regressions.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?485807CD.1030601>