GNU Grep versus the (Linux) open source ecology

June 2, 2023

One of the changes in GNU Grep 3.8 was, to quote this release notice (also the GNU Grep 3.8 release NEWS):

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.

GNU Grep's fgrep and egrep commands were already shell scripts that ran 'grep -F' or 'grep -E', so this change amounted to adding an echo to them (to standard error). Many Linux distributions immediately reverted this change (for example, Debian), but Fedora did not and so Fedora 38 eventually shipped with Grep 3.8. Fedora 38 also shipped with any number of open source packages that contain installed scripts that use 'fgrep' and 'egrep' (cf what I found on my machine), and likely more of its packages use those commands in their build scripts.

(There are reports of build failures in Gentoo (via).)

Since adding warnings and other new messages is a breaking API change, all of these packages are now broken in Fedora and by extension any other Linux distribution that packages them, uses GNU Grep 3.8 or later, and hasn't reverted this change. Some of them are only minorly broken; others, either inspecting their standard error or operating in a context where other programs expect to see and not see some things, are more seriously affected. To repair this breakage, all of these packages need to be changed to use 'grep -F' and 'grep -E' instead of fgrep and egrep.

This change is pointless make-work inflicted on the broad open source ecology by GNU Grep. GNU Grep's decision to cause these long-standing commands to emit new messages requires everyone else to go through making changes in order to return to the status quo. This is exactly the same kind of make work as other pointless API changes, and just like them it's hostile to the broad open source ecology.

(It's also hostile to actual people, but that's another topic.)

You may be tempted to say 'but it's a small change'. There are two answers. First, a small change multiplied by a large number of open source projects is a lot of work overall. Second, that this is a make-work change at all is GNU Grep deciding that other projects don't matter that much. This decision is hostile to the wider open source ecology as a matter of principle. It's especially hostile given that any number of open source projects are at best dormant, although still perfectly functional, and thus not likely to make any changes, and other open source projects will likely tell GNU Grep to get bent and not change (after all, even Linux distributions are rejecting this GNU Grep change).

Due to how Linux distribution packaging generally works, it would actually have been less harmful for the overall Linux distribution ecology if GNU Grep had simply dropped their 'fgrep' and 'egrep' cover scripts. If they had done so, Linux distributions would most likely have shipped their own cover scripts (without warnings) as additional packages; instead, GNU Grep has forced Linux distributions to patch GNU Grep itself.

PS: While GNU Grep is in theory not Linux specific, in practice only Linux uses GNU Grep. Other open source Unixes have their own versions of the grep suite, and this GNU Grep change isn't going to encourage them to switch.

(I had a string of Fediverse reactions to this change when I upgraded to Fedora 38 on my work machine. Also, when GNU Grep released 3.8 last fall I wrote about how we're stuck with egrep and fgrep.)


Comments on this page:

From 2007, "New warning messages might as well be fatal errors":

There's a widespread view that a good way of deprecating something is to have the new version of your project emit warning messages when it runs across code using whatever you're getting rid of. The theory goes that this is pretty harmless; the people using the to be removed feature will get notified about the situation but can fix their code at relative leisure, because things still work.

This change is pointless make-work inflicted on the broad open source ecology by GNU Grep.

Sorry, but this is overdramatic.

The change is trivial, doesn’t involve any major adjustments of anything, and it can be done with an one-line command like this:

grep -RZl '\<[ef]grep\>' | xargs -0 sed -Ei~ 's/\<([ef])(grep)\>/\2 -\U\1/g'

It’s giving me a lame version of Python 2→3 transition (which actualy involved major rewrites of programs), it’s The Rape of the Lock to the latter’s Iliad.

And anyways, e/fgrep were deprecated since 2007 and the documentation warned you about it for the whole time, so if you didn’t get the memo in those 16(!) years, well, that’s not the GNU’s problem. Ignorantia documentationis non excusat.

it would actually have been less harmful for the overall Linux distribution ecology if GNU Grep had simply dropped their 'fgrep' and 'egrep' cover scripts

Agreed, but for the completely opposite reason. Having a long transitional period – like here – is the single worst thing to do if you want to enact any change. It ensures that users won’t actually bother to transition, especially if there is no clear deadline, like here.

It’s funny (FSVO funny) to read the arguments in favor of this change. They basically boil down to “the wrappers should be removed because they were deprecated”. “Deprecated”, of course, just means “(someone thought this) should be removed”, so the reasoning ultimately boils down to “they should be removed because they should be removed”, laying bare the circularity and thus ultimate emptiness of the thinking here.

It’s also a bit of a boggle to have “it’s pointless work” responded to with “yeah but it’s trivial work”. Never mind that after the search+replace itself – which, sure, is relatively trivial –, you then have to review and test the results, and after you commit and push and either deploy or distribute the change, you then get to fix merge conflicts with lots of branches because of what a broad horizontal change this was. And at the end all of this work it’s still pointless – openly undisputedly so, in fact.

Written on 02 June 2023.
« Capturing data you need later when using bpftrace
Unix is not POSIX »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jun 2 22:23:24 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.