Chris SiebenmannApr 20, 2023

So Fedora 38 has chosen to break fgrep and egrep, to the fun of everyone who has them in scripts, especially scripts in crontab entries.

$ fgrep fred /dev/null
fgrep: warning: fgrep is obsolescent; using grep -F

Adding output to standard error is an *incompatible change*. And this is happening only because the GNU Grep people are <redacted because I cannot think of quite the right phrase>.

Show threadChris SiebenmannApr 20, 2023

I have filed a Fedora 38 bug over this fgrep/egrep change and we'll see if it goes anywhere. I did my best to keep my system administrator's voice down, but I did not entirely succeed in hiding my views.

https://bugzilla.redhat.com/show_bug.cgi?id=2188430

2188430 – grep-3.8 is incompatible with previous versions of grep for fgrep and egrep

Show threadChris SiebenmannApr 20, 2023
One of my opinions on egrep/fgrep versus 'grep -E' and 'grep -F' is that the former are rather nicer to type than the latter, and that matters. One extra letter, all lower case, no shifting needed. And egrep and fgrep have been there for a very long time.
Show threadChris SiebenmannApr 20, 2023
Unsurprisingly, usage of egrep and fgrep is common across the shell scripts (and probably other things) that are shipped by assorted open source packages. GNU Grep's decision to loudly deprecate and then remove these names is a giant and pointless middle finger to the general free/open source ecology, one that will require hundreds of projects to undertake pointless work just because GNU Grep people want to get rid of 'redundant' commands that have been there since, oh, V7 Unix in the 70s.
Show threadChris SiebenmannApr 26, 2023

Fedora has not accepted the fgrep/egrep bug report and says to take it upstream; Fedora doesn't patch upstream, so they say.
The GNU Grep upstream is actively hostile to reverting this user-hostile change.

This rejection leaves Fedora with a collection of packages with broken or malfunctioning scripts. Some of those upstreams will not change, and Fedora likely will not patch them to work again.

Nice work, Fedora. Nice work, GNU Grep. This is the inevitable consequence of your decisions.

Show threadAxel 🚴😷🐧🐪⌨ | #WeAreNatenomApr 26, 2023
@cks: Debian reverted that horrible grep upstream change several months ago already and IIRC intents to keep it that way forever.
Show threadAxel 🚴😷🐧🐪⌨ | #WeAreNatenomApr 26, 2023
@cks: Actually, on the commandline I never use grep. I always use either fgrep or egrep. grep itself looks to me like an unlucky bastard of both: Neither searches for literal strings nor does it have mighty enough regular expressions but instead just an (IMHO bad) compromise of both.
Show threadCsillag TamásApr 27, 2023
@xtaran @cks and not ack(1) ?
I use it more and more nowadays.
Show threadChris Siebenmann
@ttyS1 @xtaran My not-grep searcher has drifted to rg (ripgrep), although I think I was trying out ack a while back when all of them were relatively new.
Apr 27, 2023 at 2:46pmWeb
Show threadAxel 🚴😷🐧🐪⌨ | #WeAreNatenomApr 27, 2023

@cks: #ripgrep indeed seems slightly fast than normal #grep.

But for some cases it's still not fast enough. Which is why I wrote #pxzgrep, a wrapper around #xzgrep which can search through many compressed log files in parallel and—provided the hardware is capable enough—reduce search times from many days to a few hours: https://github.com/ETHZ-IT-SeC/pxzgrep

Cc @ttyS1

GitHub - ETHZ-IT-SeC/pxzgrep: a parallel xzgrep wrapper

a parallel xzgrep wrapper. Contribute to ETHZ-IT-SeC/pxzgrep development by creating an account on GitHub.

GitHub