Some context: egrep and fgrap are implemented as wrapper scripts that look like this: #!/bin/sh exec grep -E "$@" 28 bytes. Now consider the cost/ben

Some context: egrep and fgrap are implemented as wrapper scripts that look like this: #!/bin/sh exec grep -E "$@" 28 bytes. Now consider the cost/benefit between two options: 1. Maintain these wrapper scripts forever. 2. Update all scripts in the world that use these to use the flags instead, eventually removing the wrappers. What is the cost of option 1? It's essentially zero. No changes means no engineering work. Some hard drive space is wasted, but TBH you can probably buy a single hard drive with enough capacity to store all copies of these files that will ever exist. Perhaps some people's sense of cleanliness will be offended by the continued existence of non-standard commands but it's hard to demonstrate any actual cost from that. What is the cost of option 2? Many thousands of hours of engineering labor, just to update scripts. But that's just the beginning: There will likely be production outages when the script are finally removed, since inevitably some uses will be missed. That will cost money. It will also lead to a general increase in fear of software updates, leading even more people to run outdated installations that are vulnerable to security flaws. Security breaches will cost more money. It seems clear this change will cost millions of dollars, whereas keeping things as they were would have trivial cost. Therefore, this change should not have been made, and should be reverted. Reasoning like this is why widely-used platforms simply never remove "deprecated" APIs: * Java still contains APIs deprecated 25 years ago in version 1.1. * Linux's ABI is famously stable, with Linus verbally abusing anyone who even suggests a backwards-incompatible change. (I don't approve of the abuse part.) * The web platform is backwards-compatible even with objectively bad JavaScript design decisions made by Netscape in the 90's. * C libraries still include `gets()` even though any use of it implies a security vulnerability. (Though we hope any remaining users are not running in security-sensitive use cases...) * The Windows API is full of trash but you can still run executables built in the 90's. "Deprecated" was never supposed to mean "will go away". It was always supposed to mean only "there's a better way to do this".