grep 3.7 in Fedora 37: $ fgrep fred /dev/null $ grep-3.8-3.fc38.x86_64 in Fedora 38: $ fgrep fred /dev/null fgrep: warning: fgrep is obsolescent; using grep -F $ Producing additional output on standard error is an incompatible change. It does things like cause crontab jobs using fgrep (or egrep) to send people email when they didn't so so before, and it makes scripts alter their output. fgrep and egrep should not emit this new message unless it is the intention of GNU Grep to explicitly break many current uses of fgrep and egrep, and Fedora supports that. Reproducible: Always
Upstream noted this change in the NEWS for the release in 2022. https://savannah.gnu.org/news/?id=10191 ~~~ NEWS * Noteworthy changes in release 3.8 (2022-09-02) [stable] ** Changes in behavior ... The egrep and fgrep commands, which have been deprecated since release 2.5.3 (2007), now warn that they are obsolescent and should be replaced by grep -E and grep -F. ... ~~~ The intent was certainly to deprecate the feature and warn before it starts to fail after removal. It seems intentional. 1 #!@SHELL@ 2 cmd=${0##*/} 3 echo "$cmd: warning: $cmd is obsolescent; using @grep@ @option@" >&2 4 exec @grep@ @option@ "$@" The output is sent to stderr as expected for a warning error before removal in a future release.
I agree, this is clearly intentional. However, it is still an incompatibility with previous behavior. Previously, if you ran a script from crontab that used fgrep and everything went fine, the script had no output and you didn't get email. Now, in Fedora 38, the script has output on standard error and you get email. (And so on in other situations.)
(In reply to Chris Siebenmann from comment #2) > I agree, this is clearly intentional. However, it is still an > incompatibility with previous behavior. Previously, if you ran a script from > crontab that used fgrep and everything went fine, the script had no output > and you didn't get email. Now, in Fedora 38, the script has output on > standard error and you get email. (And so on in other situations.) I don't see a grep-3.8 change request filed for Fedora [1] that might have highlighted this change for review by the Fedora Engineering Steering Committee (unlike the PCRE deprecation and GNU Make 4.4 changes). Fedora maintainers are not required to file a change request, and the impact of a rebase might be missed until GA impact on users. [1] https://fedoraproject.org/wiki/Releases/38/ChangeSet I'm not the maintainer of grep, but I do maintain glibc, and there we had upstream support from Gentoo's Sam James to fix our usage (glibc commit 7df596a58cdfa763924487b8c275269de3497304 changes to use `grep -E`, otherwise we'd have been impacted in Rawhide right away). I don't know if every package is ready for this change.
On my Fedora 38 machine, the following shell scripts in /usr/bin appear to use either or both of 'egrep' and 'fgrep': antiword autoheader-2.13 autoreconf-2.13 build_firefox.sh bzgrep ccmakedep cheatmake clean-forward-declaration.sh create_makefile create_makefiles create_svnignore cscope-indexer ecryptfs-setup-private gnome-doc-prepare gparted intltoolize libgcrypt-config mtnopt pocompendium pomigrate2 pruneemptydirs rescan-scsi-bus.sh stap-report vmware-collect-host-support-info xdg-open xzgrep zipgrep zstdgrep In my /usr/sbin, the list is shorter: dkms.old exiwhat pppoe-connect pppoe-setup pppoe-start pppoe-status pppoe-stop pwmconfig
Oops, dkms.old is just lingering around from something, it's not supplied by a RPM. I believe all the others come from an assortment of RPMs.
(I thought I'd posted about a *particular* issue with this to bug-grep, but I can't find it right now.) This isn't just cosmetic, either. We've had build failures in Gentoo because of homebrew *-config scripts (like libgcrypt-config) returning new output on stderr which confuses CMake if called a certain way: https://bugs.gentoo.org/868384.
Old Fogey here: I've used egrep since it since 7th Edition UNIX (1979). My fingers know it. It is seems rude to damage or kill it. I don't use fgrep but others do. It is true that POSIX eliminated grep and egrep but they also removed cc, cpio, and tar at the same time. I sure hope Fedora doesn't eliminate those! https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html#tag_23_04_02 I'm sympathetic with eliminating clutter but one has to be judicious. If I wanted a clean slate, I'd have switched to Plan 9.
It's intended upstream change, thus any concerns with it should be addressed upstream. In downstream we shouldn't divert from upstream behavior, thus I am not going to revert this upstream change downstream.
Unfortunately i don't find, where to post upstream. However. I really wish people making such useless changes of things that work since decades should be charged every single buck of effort they cause worldwide.
Created attachment 1972498 [details] RPM bringing back fgrep and egrep without complaining output
Created attachment 1972499 [details] Source RPM for the noarch RPM bringing back egrep and fgrep without complaining output
Created attachment 1972501 [details] Source RPM of the RPM bringing back egrep and fgrep without complaining output
(In reply to Albert Flügel from comment #9) > Unfortunately i don't find, where to post upstream. However. I really wish > people making such useless changes of things that work since decades should > be charged every single buck of effort they cause worldwide. Grep upstream bugs are reported through the grep mailing list: https://www.gnu.org/software/grep/manual/html_node/Reporting-Bugs.html General/devel discussion through the devel mailing list: https://lists.gnu.org/mailman/listinfo/grep-devel
Related: Bug 2237794 - postfix logs egrep deprecation warning on startup
To install the RPM i attached above that removes the message, the following can be done: wget -O /tmp/grep-compat-1.0.0-1.fc38.noarch.rpm 'https://bugzilla.redhat.com/attachment.cgi?id=1972498' dnf install /tmp/grep-compat-1.0.0-1.fc38.noarch.rpm For whatever reason it does not work to just dnf install 'https://bugzilla.redhat.com/attachment.cgi?id=1972498'