DragonFlyBSD

In master grep has been upgraded to a newer version of gnu grep,
which doesn't include zgrep, zegrep, zfgrep.

I usually install textproc/bsdgrep-devel from pkgsrc,
which includes programs like the missing ones
(an extra 'b' is in the name);
links for zgrep etc to bsdgrep programs
can be made where you prefer, e.g. /usr/local/bin.

/usr/src/UPGRADING should be updated with this info.

-thomas

On 08/27/11 17:48, Thomas Nikolajsen (via DragonFly issue tracker) wrote:

In master grep has been upgraded to a newer version of gnu grep,
which doesn't include zgrep, zegrep, zfgrep.

should we just put in shell wrappers for these?

seems like that would be pretty straightforward and wouldn't
require an extra package for functionality...

dunno.

cheers,

- Chris

should we just put in shell wrappers for these?

I don't think you can get same functionality with shell wrappers;
for this you will have to decompress whole directory tree before grep'ing;
this isn't an option.

seems like that would be pretty straightforward and wouldn't
require an extra package for functionality...

It would be nice to have zgrep etc. in base again before next release.

-thomas

On 08/29/11 16:01, Thomas Nikolajsen (via DragonFly issue tracker) wrote:

should we just put in shell wrappers for these?

I don't think you can get same functionality with shell wrappers;
for this you will have to decompress whole directory tree before grep'ing;
this isn't an option.

curious - what's the use case here?

I've only used these individually e.g.

zgrep kernel /var/log/messages.0.gz

etc.

Use case could be:
zgrep -l XXX *.gz

Translating that like 'for X; do zcat "$X" | grep -l XXX; done'
will not show correct file name.

Also 'zgrep kernel /var/log/messages.0.gz /dev/null'
will have similar problem.

What is best way to resolve this?

I see three options:
1) revert to previous grep;
I'm not aware of any benefit from upgrading.
2) install other zgrep (etc) program in base
3) accept missing zgrep (etc) and document in UPDATING

On Tue, Sep 27, 2011 at 10:12:23PM +0000, Thomas Nikolajsen (via DragonFly issue tracker) wrote:

Thomas Nikolajsen <thomas.nikolajsen@mail.dk> added the comment:

What is best way to resolve this?

I see three options:
1) revert to previous grep;
I'm not aware of any benefit from upgrading.

I'm fond of --color option in the newer grep program :)

2) install other zgrep (etc) program in base
3) accept missing zgrep (etc) and document in UPDATING

When we switched to libz-based gzip, we also obtained the z*grep script
in our tree, but it didn't work because our grep program was too old,
and it natively supported gzip'ped files, so simply the script wasn't
needed to be installed. The gzip support in grep was probably FreeBSD-
local modification, so someone can merge it for the new version, too,
but until that happens, here's a small patch to re-activate the z*grep
script. I can commit it later today, if there's no objection.

diff --git a/Makefile_upgrade.inc b/Makefile_upgrade.inc
index d43f64f..1a09924 100644
--- a/Makefile_upgrade.inc
++ b/Makefile_upgrade.inc
@ -1588,15 +1588,6 @ TO_REMOVE=/usr/share/man/cat9/memoryallocators.9.gz
TO_REMOVE+=/usr/share/man/man9/memoryallocators.9.gz
TO_REMOVE+=/usr/share/man/cat4/rc.4.gz
TO_REMOVE+=/usr/share/man/man4/rc.4.gz
TO_REMOVE+=/usr/bin/zegrep
-TO_REMOVE+=/usr/share/man/cat1/zegrep.1.gz
-TO_REMOVE+=/usr/share/man/man1/zegrep.1.gz
-TO_REMOVE+=/usr/bin/zfgrep
-TO_REMOVE+=/usr/share/man/cat1/zfgrep.1.gz
-TO_REMOVE+=/usr/share/man/man1/zfgrep.1.gz
-TO_REMOVE+=/usr/bin/zgrep
-TO_REMOVE+=/usr/share/man/cat1/zgrep.1.gz
-TO_REMOVE+=/usr/share/man/man1/zgrep.1.gz
TO_REMOVE+=/usr/include/dev/disk/mpt/mpilib/fc_log.h
TO_REMOVE+=/boot/kernel/ipl.ko
TO_REMOVE+=/etc/periodic/security/510.ipfdenied
diff --git a/usr.bin/gzip/Makefile b/usr.bin/gzip/Makefile
index 38e8d05..9fe453a 100644
-- a/usr.bin/gzip/Makefile
+++ b/usr.bin/gzip/Makefile
@ -2,7 +2,7 @ # $DragonFly: src/usr.bin/gzip/Makefile,v 1.5 2007/08/27 16:50:54 pavalos Exp $

PROG=        gzip
-MAN=        gzip.1 gzexe.1 zdiff.1 zforce.1 zmore.1 znew.1
+MAN=        gzip.1 gzexe.1 zdiff.1 zforce.1 zgrep.1 zmore.1 znew.1

DPADD=        ${LIBZ}
 LDADD=        -lz
@ -19,18 +19,22 @ LDADD+=        -lbz2
 CFLAGS+=    -DNO_BZIP2_SUPPORT
 .endif

-SCRIPTS= gzexe zdiff zforce zmore znew
+SCRIPTS= gzexe zdiff zforce zgrep zmore znew

MLINKS+=    gzip.1 gunzip.1 \
         gzip.1 gzcat.1 \
         gzip.1 zcat.1 \
         zdiff.1 zcmp.1 \
+        zgrep.1 zegrep.1 \
+        zgrep.1 zfgrep.1 \
         zmore.1    zless.1

LINKS+=        ${BINDIR}/gzip ${BINDIR}/gunzip \
         ${BINDIR}/gzip ${BINDIR}/gzcat \
         ${BINDIR}/gzip ${BINDIR}/zcat \
         ${BINDIR}/zdiff ${BINDIR}/zcmp \
+        ${BINDIR}/zgrep ${BINDIR}/zegrep \
+        ${BINDIR}/zgrep ${BINDIR}/zfgrep \
         ${BINDIR}/zmore ${BINDIR}/zless

.include <bsd.prog.mk>

Nice; please commit.

Didn't notice --label=FILE option on new grep;
grep.1 even hints on zgrep use.

New zgrep isn't perfect: doesn't support -r (or -d ACTION),
-iv (only -i -v) or multiple -e PATTERN,
but this should be easy to fix.

PS: Your patch has a few files TO_REMOVE which aren't related to zgrep

On Wed, Sep 28, 2011 at 10:25:48PM +0000, Thomas Nikolajsen (via DragonFly issue tracker) wrote:

New zgrep isn't perfect: doesn't support -r (or -d ACTION),
-iv (only -i -v) or multiple -e PATTERN,
but this should be easy to fix.

Hmm, you can use find command to mimic -r or -d behavior and
getopt(s) to cope with -iv. Do you have a good idea to
do a proper quoting for -e options passed to grep, for instance,
zgrep -e 'foo bar' -e '".*"' ?

PS: Your patch has a few files TO_REMOVE which aren't related to zgrep

TO_REMOVE lines for z{,e,f}grep and their manpages should be removed
otherwise you're going to remove them when you do `make upgrade', or
are we talking about something else?

Cheers.

The Makefile_upgrade.inc change looks ok. Please commit. :)

Thanks for committing patch to reintroduce z*grep!

I will close this issue shortly as missing zgrep is the issue.

Please disregard my comments on TO_REMOVE; I must have been fuzzy.

Regarding current zgrep shell script, I plan to enhance it somewhat.
The solutions you describe also appeared to me;
but the problems you raise also seem hard to me; I blame sh(1).