It's my position that the user shouldn't be subjected to this: pylon 55 # fgrep 3c:ec:ef:fc:9f:f2 /usr/local/arpwatch/arp_mvneta0.4091.dat fgrep: warning: fgrep is obsolescent; using /usr/local/bin/ggrep -F 3c:ec:ef:fc:9f:f2 172.16.1.2 1677436308 ice 3c:ec:ef:fc:9f:f2 172.16.1.15 1677297786 ice2 Simply because /usr/local/bin comes before /usr/bin in their path. Could we please have an option to control this? What I'd prefer is an option to only install ggrep. And/or an option to remove the unhelpful warnings (default on). I'm happy to generate a patch based on maintainer feedback.
(In reply to Craig Leres from comment #0) > What I'd prefer is an option to only install ggrep. Would the following be good enough? Pseudo-patch: +New option: COMPAT +COMPAT_DESC= Create g-prefixless compatibility symlinks -post-install: +post-install-COMPAT-on: .for p in grep egrep fgrep ${LN} -sf g${p} ${STAGEDIR}${PREFIX}/bin/${p} .endfor > And/or an option to remove the unhelpful warnings (default on). Leaving aside the argument about their (un)helpfulness, these are part of the upstream code/build and I'd rather not monkey-patch them away unless there is a straightforward way to disable them, e.g. via configure switch, I'll have a look.
(In reply to Alexey Dokuchaev from comment #1) > Would the following be good enough? Pseudo-patch: Yes! > Leaving aside the argument about their (un)helpfulness, these are > part of the upstream code/build and I'd rather not monkey-patch > them away unless there is a straightforward way to disable them, > e.g. via configure switch, I'll have a look. I was thinking something like this: +post-patch-NONAG-on: + @${REINPLACE_CMD} 's/^echo/#&/' ${WRKSRC}/src/egrep.sh But given that I'm unlikely to accidentally type gegrep or gfgrep this isn't critical to me. But it would allow users the option of turning on COMPAT and NONAG, putting /usr/local/bin earlier than /usr/bin on their path, and replacing the base system fgrep and egrep with the gnu version while not having to suffer the nags.
(In reply to Craig Leres from comment #2) > +post-patch-NONAG-on: > + @${REINPLACE_CMD} 's/^echo/#&/' ${WRKSRC}/src/egrep.sh Yeah, this is what I meant by monkey-patching, it's rather ugly and, admittedly, deprecation warnings should not be muted, but people should rather fix their scripts.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=cf64aa2940678ec14efb53f981b3e4bdfd25dd61 commit cf64aa2940678ec14efb53f981b3e4bdfd25dd61 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2023-03-08 14:28:04 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2023-03-08 14:28:04 +0000 textproc/gnugrep: update GNU grep to version 3.9 Allow to inhibit creation of g-prefixless compatibility symlinks via the COMPAT option (on by default). Reported by: portscout PR: 269840 textproc/gnugrep/Makefile | 9 +++++---- textproc/gnugrep/distinfo | 6 +++--- textproc/gnugrep/pkg-plist | 6 +++--- 3 files changed, 11 insertions(+), 10 deletions(-)
(In reply to Alexey Dokuchaev from comment #3) > ... deprecation warnings should not be muted, but people should > rather fix their scripts. I totally agree with that. What I don't agree with is that this a legit deprecation warning. It's wishful thinking (at best). Thank you very much for the fix.
(In reply to Alexey Dokuchaev from comment #3) The why haven't we, FreeBSD, added the same deprecation warning? Just because something isn't POSIX doesn't mean it is deprecated. egrep and fgrep have been on BSD systems since 4.1. $ cd /src/CSRG/src/usr.bin/grep/egrep $ cvs -d /src/CSRG/Cvs log egrep.c ---------------------------- revision 5.1 date: 1987/10/03 16:27:25; author: bostic; state: Exp; Initial revision ========================================================= 'man egrep' nor 'man fgrep' on my 14.0-RELEASE-p6 workstation says anything about the commands being "deprecated".