Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

utcc.utoronto.ca

Post reply on HN
Print view View original

131–140 of 354 posts

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

#131

Post by drewg123 »

Izkata wrote: post #122
drewg123 wrote: post #97

I got this obnoxious whine from egrep on FreeBSD after my latest update. This post made me look, and I had gnu grep install as a dependency for something. Once I removed it, sanity is back and the built-in BSD egrep doesn't whine. On FreeBSD, they are all the same: $ ls -li /usr/bin/egrep /usr/bin/fgrep /usr/bin/grep /usr/bin/rgrep 281835 -r-xr-xr-x 4 root wheel 30736 Sep 26 14:37 /usr/bin/egrep 281835 -r-xr-xr-x 4 r…

I didn't check where they came from, but on Ubuntu 18.04: egrep, fgrep, and rgrep are shell scripts that call grep with -E, -F, and -r

On FreeBSD, it checks the first character of the program name and modifies behavior based on that. See https://github.com/freebsd/freebsd-src/blob/main/usr.bin/gre...

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

#132

Post by thomascgalvin »

mcv wrote: post #72
thomascgalvin wrote: post #56

Earlier quoted context omitted.

> If you're relying on random globals (like the path /usr/bin/egrep) to (a) exist and (b) behave in a certain way, then don't mutate them. It's a bit old now, but one of the principles of Twelve Factor Applications is to vendor-in all of your dependencies.[1] > A twelve-factor app never relies on implicit existence of system-wide packages. It declares all dependencies, completely and exactly, via a dependency declara…

You're protected, but it also means you can never upgrade anything. An application can never know what future versions of a dependency it can work with (because a new version might contain a breaking change), so it will always require versions that existed at the time of its own creation. But those versions might contain vulnerabilities, and the new version might fix those while being fully compatible in every other…

> You're protected, but it also means you can never upgrade anything.

You're protected, and it means you have to test your system _before_ upgrading.

Also, I think I'm working with a much broader definition of what "a dependency" is than you are. I consider `Alpine Linux 3.16.2` to be an atomic thing; I don't try to track the state of every single binary that comes along for the ride.

But if I depend on something to be executable from my application, like `ffmpeg 5.1.2` or whatever, I _would_ version lock that, and install it myself as part of the build script.

Then, when `Alpine 3.17` or `ffmpeg 5.2` comes out, I can bump to those versions, run our integration tests, and verify nothing broke.

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

#133

Post by phailhaus »

Ensorceled wrote: post #26
roenxi wrote: post #12

Earlier quoted context omitted.

This is free software. It is legitimate to consider convenience for the maintainers. If they don't want to maintain two symlinks then they are empowered to make that call. If anyone thinks it is a big enough problem that they want to fork the software they can, or the distros can maintain their own symlinks. But I think in this case the simple answer is if the maintainer doesn't want it in the source tarball then it…

I don't know when society in general just said "Fuck It" to the idea of stewardship; but we now have it ingrained that people in positions of trust and power (whether volunteered, elected or appointed) are not morally or ethically beholden or responsible to the communities they have taken it upon themselves to represent. At least we used to pay lip service to that ideal.

This is "back in my day"-levels of lazy armchair criticism. Nothing has changed. People will always make decisions that you disagree with, and they are more likely than not doing it in a good faith attempt to benefit the community. These sorts of inflammatory and hyperbolic comments help nobody, and are just childishly over-the-top. egrep going away is not evidence of moral or ethical bankruptcy, just wow.

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

#135

Post by tuetuopay »

mannykannot wrote: post #18
tuetuopay wrote: post #14

Earlier quoted context omitted.

It's more than likely the warning will be printed to stderr, not out, so there will be no impact on the actual work done.

Automatically monitoring the stderr from cron jobs for unusual outputs is a prudent measure, and its plausible that this change will increase the burden of false positives (it certainly will not reduce it.)

hence why I wrote "actual work done".

your scripts will continue to produce the expected output. the side effects, otoh, will change indeed.

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

#136

Post by waffletower »

It is depressing, even sickening how common such exercises in tunnel-vision vigilantism occur among software engineers. The same lack of understanding of downstream impacts is found in library maintainers that use auto-updating transitive dependencies, for example.

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

#137

Post by bitofhope »

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

I can't really see the difference. Adding a deprecation warning to stderr in a non-POSIX command 15 years after deprecation notice is among the smallest possible changes to [GNU's Not] Unix I can think of. Even then, the change is trivially silenced by deleting a single line in a shell script or two[1] and seems that some distros already do that for you[2].

Yes, this will break something for someone[3] and I might well be that someone. You truly have my sympathies. But if you want to run a system for a decade and a half without ever needing changes, stick to POSIX. You can't have your fossils and eat them too.

[1] https://git.savannah.gnu.org/cgit/grep.git/commit/src/egrep.... [2] https://github.com/void-linux/void-packages/pull/39340 [3] https://xkcd.com/1172/

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

#138

Post by aftbit »

On my system, egrep and fgrep are _already_ shell scripts, just changed to add the stupid warning:

    $ cat =egrep =fgrep
    #!/bin/sh
    cmd=${0##*/}
    echo "$cmd: warning: $cmd is obsolescent; using grep -E" >&2
    exec grep -E "$@"
    #!/bin/sh
    cmd=${0##*/}
    echo "$cmd: warning: $cmd is obsolescent; using grep -F" >&2
    exec grep -F "$@"
Looking at src/egrep.sh in the git repo[1], I see that before this warning was added in 2021, the last change was back in 2015. In fact, since the git repo history began in 1998, there have been a total of 4 changes to this file. Clearly the maintenance burden of these scripts is not sufficient to require the maintainers to drop them. My guess... this is being done out of some weird sense of purity over practicality. Bad call by Paul Eggert IMO[2].

1: https://savannah.gnu.org/git/?group=grep

2: commit a9515624709865d480e3142fd959bccd1c9372d1 added the warnings

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

#139

Post by mrybczyn »

Tool devs should get to decide on functionality - and then it's up to the distro maintainers to make aliases and organize well into their distros. Here it seems that the former are encroaching on the latter, for historical reasons?

By the way:

    ~$ bgrep
    Command 'bgrep' not found, but there are 20 similar ones.
There's not many [a-z]grep's left in the alphabet, reserve yours now :-)

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

#140

Post by PaulHoule »

barrkel wrote: post #114
radford-neal wrote: post #107

I use fgrep all the time. Why should I spend time converting scripts, and retraining my fingers, and forever after taking longer to type grep -F? This is a breaking change that has no upside, only downside. It is idiocy. Just to elaborate, there must be many thousands (hundreds of thousands? millions?) of shell scripts out there that use fgrep. For no reason at all (whatever maintenance burden fgrep represents must b…

There's a certain type of person who gets pleasure from following rules exactly, particularly when other people don't follow those rules. A kind of smug moral superiority. If they get into a position of power, they can make life worse for other people, without much regard for the actual cost of breaking such rules. Removing egrep and fgrep is desperately petty stuff.

It’s a show of how free software partisans are often out of touch.

The cost of egrep and fgrep is just two symbolic links. Some people though would rather talk about ‘libre’ and ‘free as in speech’ and ‘free as in beer’ than talk at all about the user experience. And they wonder why most people just run windows or macOS, but they’ll never understand.

Post reply on HN