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

81–90 of 354 posts

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

#81

Post by cestith »

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

Well, really, the type of purity many of the original Unix hands desired was that each tool did one thing well, not that one tool did everything well. Some folks would say that putting the -E and -F flags in GNU grep in the first place instead of using egrep and fgrep was the wrong direction. Now GNU is wanting to further consolidate the hydra.

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

#82

Post by koprulusector »

Beltalowda wrote: post #27
emptyparadise wrote: post #20

Earlier quoted context omitted.

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

Of course it can be solved; no one claimed you can't. The choice here is: - Thousands of users have to update their scripts, habits, shell configs; or - The GNU Grep maintainers spend essentially zero minutes "maintaining" a few lines of code to automatically use -E or -F based on argv[0]. It seems to me the second is obviously the better option.

    # unalias grep && unalias egrep && cp "$(command -v grep)" "$(dirname "$(command -v grep)")/egrep"
1 line. Fixed. Done. Btw needs to be run as root ( as signified by # prompt above)

EDIT: see other comment in this thread from FreeBSD user that on FreeBSD grep, egrep, and fgrep are all separate but identical (copies) of the same file. So this isn’t quite such a silly solution as some might think.

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

#83

Post by joshuacc »

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…

Isn’t that essentially semantic versioning plus version ranges ala npm?

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

#84

Post by rgoulter »

sillysaurusx wrote: post #76
chriswarbo wrote: post #37

I get the annoyance, for both the GNU maintainers and distro maintainers/sysadmins. I'm not too wedded to either outcome, but my take is that we should avoid global mutable state: - 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. Stick with known-good versions, and treat updates like any other code change (review, test, etc.). Th…

(I want to love Nix, but it’s so foreign. I do hope it becomes more of a standard. It’s just hard to learn and hard to use until you learn.)

I'd prefer to qualify that a bit:

When you can get Nix to do what you want, it's wonderful.

When you hit a barrier (e.g. a program you want isn't packaged), that's when Nix is very hard to use, and requires learning.

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

#85

Post by eptcyka »

AshamedCaptain wrote: post #50
chriswarbo wrote: post #37

I get the annoyance, for both the GNU maintainers and distro maintainers/sysadmins. I'm not too wedded to either outcome, but my take is that we should avoid global mutable state: - 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. Stick with known-good versions, and treat updates like any other code change (review, test, etc.). Th…

Both of your suggestions are basically equivalent to "think before you upgrade" and/or "don't upgrade". This is the second elephant in the room with all these distros that "don't use globals" and/or statically link everything (or do an analogue to that, like nix). There's very little benefit for desktops. So the upgrade to dependency X breaks component Y, and you are forced not to update X, or at least, Y's copy of X…

Yes, but Nix just solves this nicely enough.

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

#86

Post by Ensorceled »

asoneth wrote: post #63
Ensorceled wrote: post #26

Earlier quoted context omitted.

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.

> At least we used to pay lip service to that ideal. When was that? For as long as I can recall, a core mantra of free/libre software has been that it was provided "AS IS" without warranty of any kind. Decades ago the dominant response I recall was one of gratitude and a little amazement that ad-hoc communities of volunteers were making real software that wasn't just academic but on par with commercial offerings. Som…

Well, concurrent with this decline in stewardship has been a decline in graciousness towards volunteers, so I see your point.

I remember when I was younger, every volunteering experience I had was a delight; people thanking me for my time, getting me free coffee "just because", etc. Some of my more recent volunteering experiences have been less pleasant.

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

#87

Post by dspillett »

Beltalowda wrote: post #22
xpressvideoz wrote: post #5

> The egrep and fgrep commands have been deprecated since 2007. Isn't 15 years more than enough time to handle the deprecation?

I betcha most people didn't even know they were considered "deprecated".

I for one didn't know they were properly deprecated.

Though I've not used either since uni over two decades ago¹ on a somewhat off-standard Unix a few of the machines ran, so until this thread I can't say I was remembering that they existed at all.

----

[1] using grep -E when needed since²

[2] and presumably grep -F too though I don't remember ever actually doing that

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

#88

Post by jagtesh »

What’s wrong with removing the commands and adding shell aliases instead? That sounds perfectly reasonable to me.

eg. In bash, they can be expressed as:

alias fgrep=grep -F

alias egrep=egrep -E

This sounds like a push for purity - similar to what happened in Python 3 with the move from print “xyz” (special keyword) to print(“xyz”) (standard function).

The new function requires three additional keystrokes every time it is used.

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

#89

Post by ufo »

mannykannot wrote: post #15
ufo wrote: post #8

The blog makes two main points: 1) adding new error messages causes compatibility problems; 2) some people are used to typing "egrep". On the first point the author only gives hypothetical examples. I feel the argument might have been more compelling if we could see some concrete examples of things that break with GNU Grep 3.8. As for the second point, I find it less convincing than the first one. If it's just the mu…

With regard to the first point, the examples may be hypothetical, but they are also very plausible. When a change has little or no objective benefit, I feel the burden of demonstrating that it is harmless falls on those making the change. As has been pointed out elsewhere, this is free software and the maintainers are free to do whatever they like. That does not stop others having an opinion about it, especially when…

Sure, but it would still be nice to have at least one such example. Looking at the rest of the discussion thread here on HN as of now it's still only hypotheticals.

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

#90

Post by zorked »

jagtesh wrote: post #88

What’s wrong with removing the commands and adding shell aliases instead? That sounds perfectly reasonable to me. eg. In bash, they can be expressed as: alias fgrep=grep -F alias egrep=egrep -E This sounds like a push for purity - similar to what happened in Python 3 with the move from print “xyz” (special keyword) to print(“xyz”) (standard function). The new function requires three additional keystrokes every time i…

It breaks my script that calls /usr/bin/fgrep
Post reply on HN