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>.
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.
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.
@cks this is gold!
GNU […] fit of narrow POSIX compliance
/bin/false --version, anyone? (At least it doesn’t return 0 any more, or at least in Debian it doesn’t…)
That's the thing. The GNU egrep and fgrep _already are_ shell scripts. Paul Eggert added this change _to those shell scripts_.
@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
> How is this relevant?
It's a discussion about grep(1) options, which could lead to an interesting discussion about the regex differences between "grep -E" and "grep -P".
> What either of us prefers doesn't mean that our preferences work their way into everyone else's code.
I'm not saying they should. Curious how you read that from my reply.
@cks Here's what Pat Volkerding, creator of Slackware, has to say about this:
"a/grep-3.8-x86_64-2.txz: Rebuilt.
Folks, I rarely veto upstream, but I'm not going to entertain this nonsense. The egrep and fgrep commands were part of Unix since the 70s, continue to be included with the BSDs, and frankly, aren't hurting anything. GNU grep declared them deprecated in 2007 and when they were changed into shell scripts around 8 years ago I figured that's where it would end."
(1/3)
@cks
"I can see no logical justification to have these scripts start making noise and then to eventually pull the rug out from under any code that might be using them, so I've placed non-noisy versions of them into the package sources and will be installing those during the build. Given that the -F and -E options are part of the POSIX standard, these scripts will continue to work fine."
(2/3)
"That said, we will be continuing to change our own code over to the recommended syntax to avoid the minimal overhead incurred compared to using grep directly."
from the Slackware changelog ( http://slackware.nl/slackware/slackware64-current/ChangeLog.txt ), on Sep 7
@cks @ltlnx we had the same thing with GNU loudly warning about tail -1 ipv the newer POSIX tail -n 1, especially as many systems didn’t yet carry the latter, at that time even OpenBSD not.
The Debian package got enough complains this idiocy was patched out (I wonder if it was removed upstream as well).
One would think the GNU coreutils maintainers learnt from this desaster…
@cks The rather obvious fix against this obsoletion/code replication would of course be to:
- still create only one binary target
- which has the smarts to enable evaluation as RE’s as Extended RE’s when invoked as “egrep”, and to treat the match pattern as fixed strings rather than RE’s when invoked as “fgrep”
One binary, three hard links, no code duplication, no middle finger to existing scripting.
@dead10ck Well, in actual practice Fedora dropped this change into a regular release with no particular notice and without auditing the shipped scripts and so on for egrep and fgrep usage. The breakage is not small in my sysadmin opinion, partly due to crontabs.
And GNU Grep is demanding every project in the world with shell code (or that exec things) audit it for fgrep/egrep usage, or else. That's not small.
@cks @dead10ck It's probably fair that the Fedora maintainer could have considered a change proposal for this to raise visibility. It's just a deprecation warning, but I acknowledge the points you've raised about the ways it can have a outsized impact.
That said, Fedora X to X+1 is absolutely a major version upgrade. Fedora is known for innovation because every six months there is an opportunity for major changes. Maintainers don't have to wait years to deliver backwards-incompatible software.
Chris Siebenmann
mirabilos
penguin42
cesarb
JdeBP
Axel 🚴😷🐧🐪⌨ | #WeAreNatenom
Csillag Tamás
Aaron Toponce ⚛️
Orc
Robert Thau
rsalz
mx alex tax1a - 2020 (6)
Steve Bellovin
Norman Wilson
Jef Poskanzer
mL
J$
mathew
Christoph Petrausch
gunstick
Skyler Hawthorne 
Carl George 
RAK
Kevin Davidson
Elias Probst
Rob Landley
Leonardo Ferreira Fontenelle
Haelwenn /элвэн/ 
grep -P
tusooa 
西风 
argv[0] is nothing, specially compared to all the stuff GNU does).@cks We ended up making the decision in Gentoo to by default install our own fgrep and egrep but allow disabling it if people want the warnings (and eventually them to be entirely gone, I suppose).
It's not worth the breakage. I did plea on the grep mailing lists but didn't get anywhere.
sam
Carlos O'Donell
Björn
Steven Reed