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.)