We are stuck with egrep and fgrep (unless you like beating people)

October 12, 2022

Over on Twitter I had a reaction:

I see that a bunch of system administrators (or distribution packagers) are going to set GNU Grep 3.8 on fire with the power of their minds. Spoiler: new warnings are an API change.

What's special about GNU Grep 3.8 is that its version of egrep and fgrep now print an extra message when you run them. Specifically, these messages 'warn' (ie nag) you to stop using them and use 'grep -E' and 'grep -F' instead.

(I assume that these messages are printed to standard error, because not even GNU Grep would be so hostile as to put them in standard output.)

There are two problems with this. The first issue is what's going to cause system administrators and distribution packagers to set GNU Grep 3.8 on fire, which is that in practice adding warnings and other new messages is a breaking API change. There are many places where adding new messages will cause breakage and pain (for example, in scripts run from cron where unexpected output will result in the sysadmins getting mailed, perhaps a lot).

The second issue is that this is unpleasant to actual people. There are a lot of people who are used to using (and typing) 'fgrep' and to a lesser extent 'egrep' when they want certain sorts of results from grep. These people don't care that the people behind GNU Grep (and POSIX) don't like these commands; they are used to them, and now they're being nagged (and threatened with actual removal). There's also a lot of writing about Unix out there in the world that uses 'fgrep' and 'egrep'; GNU Grep wants to make all of this perfectly good writing less useful. It doesn't matter to GNU Grep that fgrep and egrep have been present in Unix since V7. Out they go, because POSIX says so.

As a side note, I believe that one reason that people continue using fgrep and egrep is simply that they're easier and faster to type. Typing 'fgrep' is one continuous run of lower case letters; typing 'grep -F' is two more characters, one of them shifted. People are lazy, and GNU Grep wants them to work harder for no particularly good reason.

(Or it wants everyone in the world to create their own 'fgrep' and 'egrep' cover scripts, which is a terrible amount of redundant work.)

If Unix didn't already have fgrep and egrep, people probably wouldn't add them. But this isn't the world we have; this is a world where fgrep and egrep have been around for over 40 years. In that world, Unix is stuck with them unless you want to beat up people's scripts, documentation, writing, habits, and reflexes. Doing that is not progress or being friendly to people.

(I'm definitely not in favor of fossilizing Unix, but there's a difference between avoiding fossilization and the kind of minimal, mathematical purity that we see GNU Grep trying to impose here. Unix has long since passed the point where it had that sort of minimalism in the standard commands. Modern Unix has all sorts of duplications and flourishes that aren't strictly necessary, and for good reasons. One of them is that it's nicer for the actual people using Unix. You don't strictly speaking need 'sort -h', but it's quite convenient.)


Comments on this page:

Spoiler: new warnings are an API change.

adding warnings and other new messages is a breaking API change

This is obviously insane. Once again, this is the typical UNIX attitude at play, in which not following conventions or anything else is allowed but don't actually do it now, since that would be crazy. Now, the fact that new warnings can do this are evidence UNIX has no real warning signalling facility, but that's besides the point.

It's clear to me that UNIX is garbage, but people have been eating it for so long they know no longer what food is.

Unix has long since passed the point where it had that sort of minimalism in the standard commands.

UNIX never had true minimalism, that actually simplifies anything.

Modern Unix has all sorts of duplications and flourishes that aren't strictly necessary, and for good reasons.

The original UNIX was also stuffed with duplicated functionality. It was never beautiful and pure.

By Etienne Dechamps at 2022-10-15 14:31:52:

I first noticed these warnings when various cron jobs suddenly started emailing me because of the spurious stderr output.

People got so annoyed by them that Debian removed them altogether shortly after they showed up in Sid.

The 3.6 versions of egrep and fgrep are small placeholder scripts with the appropriate -E or -F flag:

   #!/bin/sh
   exec grep -E "$@"

The new version just echoes the stupid warning before exec. I'd just replace it with the old two-line version.

By jbowen at 2022-10-20 22:23:51:

I actually tend to use grep [-E|-F]. In my mind, I want to grep for something, so I type it, then I decide I want to use extended regexes or exact matching and add the option. It just fits better with my mental model.

That being said, I have no idea why GNU grep wants to be strictly POSIX compliant and are picking this fight. They should generally support POSIX features, but it's perfectly fine to have extensions which add features beyond POSIX.

Written on 12 October 2022.
« When Promtail seems to make position checkpoints (as of v2.6.1)
We're moving away from swap partitions on our Linux servers »

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

Last modified: Wed Oct 12 21:42:24 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.