GNU Grep versus the (Linux) open source ecology | Hacker News Reader

GNU Grep versus the (Linux) open source ecology

utcc.utoronto.ca

8 pointstodsacerdoti10 comments

There seems to be always someone who comes along who hasn't run `file /usr/bin/fgrep` on a relevant operating system that uses GNU tooling and opines that "They could always just replace them with 2-line shell scripts.". There no doubt will be someone on Hacker News.

They already were 2-line shell scripts.

When Paul Eggert made the change in August 2021, xe changed a 2-line shell script into a 4-line shell script with an echo >&2 in the middle.

"deprecated since release 2.5.3 (2007)".

15 years wasn't enough time to update?

Perhaps not if they weren't broken in an easily apparent way.

I think almost no one knew it was deprecated. It's been in Unix since 1979, and it's a two-line shell script – I don't really see what the point of deprecating let alone removing it is.

Shouldn't the package maintainers for the big distributions be paying attention to things like this? RedHat was able to notice that the LibreOffice rpms were orphaned and drop support for it.

Perhaps the deprecation could have been communicated more broadly, but really, in 15 years, nobody looked at the release notes and thought to make a change?

> in 15 years, nobody looked at the release notes and thought to make a change?

What change could have been made? Package managers can't "just" remove it as that would break people's scripts, and adding their own warning message leaves us where we are now. I suppose a package-message could be added, but I don't think anyone expected that [ef]grep would start printing warning messages all of the sudden – lots of things are "deprecated" but still work and will likely continue to work for decades to come – so why bother?

Why bother deprecating things if they aren’t ever going to be removed? With deprecate and remove them after a reasonable time or don’t bother.

You can discourage people from using it while still maintaining compatibility.

I have a Go library with some functions that have been deprecated since Go 1.1 (2013); they're just some aliases or wrappers for the newer symbols. They will stay there forever until I have enough reason to release a v2 (which may be never). POSIX also includes plenty of legacy/deprecated stuff like mktemp() that will likely never be removed.

A CLI is a public interface; breaking compatibility is kinda bad.

The complainant who set this off (by filing a GNU bug report) said the same. Ironically, several people missed that one of xyr acceptable outcomes was just removing the claim about deprecation from the manual page.

The just shy of 40 years of having these tools as standard (They were in the SVID. They were also in Bourne's book.) militates against that.

Reply on news.ycombinator.com