We are stuck with egrep and fgrep (unless you like beating people) • Hacker News Board

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

#91

Post by ajross » Thu, Oct 13, 2022, 1:39 PM UTC

teddyh wrote: post #66

ajross wrote: post #34

Earlier quoted context omitted.

> On the first point the author only gives hypothetical examples I have scripts everywhere , some of them 20 years old or more, that use fgrep. For years and years it was a "best practice" thing if you were checking for a fixed string (so that you didn't accidentally match on a "." or whatever by forgetting it was a regex).

You have two options: The first option is to simply replace "fgrep" with "grep -F" everywhere in all your scripts, which is correct but is more work than your other option, which is to add your own "fgrep" script somewhere in your path. Any of these options seem reasonable to me.

OK, are you going to call up all my former employers to tell them to audit the scripts I wrote for them in the late 90's?

I really don't think people understand the impact here. It's not it's just a bunch of angry geriatric graybeards yelling at the modern world. It's that there is decades of uncounted, unrecognized, untraceable software written using these old conventions that are suddenly changing.

It's just a terrible idea. Linux cares about conforming to syscall interfaces for binaries compiled 20 years ago, but somehow you think it's OK to break scripts that have worked fine for 50 (fifty!) years?

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

#92

Post by henearkr » Thu, Oct 13, 2022, 1:40 PM UTC

They (the maintainer) should make the behavior of `grep` depending on the name of the executable.

Then one could simply do a `ln -s grep egrep` and be done with it.

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

#93

Post by Ensorceled » Thu, Oct 13, 2022, 1:41 PM UTC

SkyBelow wrote: post #51

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.

One major issue with humans is that sacrifice begins to be expected and often is not rewarded. When a job not only becomes thankless, or near enough, but also expected as the default, it becomes hurtful to continue doing it. Are the stewards being provided fair compensation? How do we even talk about what is fair compensation when non-monetary compensation has become difficult to even discuss (often due to past insta…

> One major issue with humans is that sacrifice begins to be expected and often is not rewarded. When a job not only becomes thankless, or near enough, but also expected as the default, it becomes hurtful to continue doing it.

Oh, most definitely. The anger and vitriol I see directed towards maintainers, or volunteers of any type, who are "stepping back for personal reasons" is horrifying.

My father was a very active volunteer in his community ... the number of people who were mad at him when he stepped away after his heart problems was startling. Conversely, the number of people who volunteered to help him and my mother with shopping etc. when COVID hit was heart warming.

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

#94

Post by Pxtl » Thu, Oct 13, 2022, 1:41 PM UTC

I do wish that there was a standard pipeline for warnings, so stuff like this didn't have to go into error (bad) or output (worse). Powershell has such a feature but of course since it's not at the OS/Posix level then support is spotty.

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

#95

Post by tyingq » Thu, Oct 13, 2022, 1:43 PM UTC

koprulusector wrote: post #58

I’ve been using grep -E for a long time, I thought I remember it being from a warning from egrep or something.. can’t really remember for sure, though. Either way, I don’t see what the big deal is, just add an alias egrep='grep -E' If you’re worried about your non-interactive shell scripts, shopt -s expand_aliases; alias egrep='grep -E' and you can move on with your life. EDIT: I must’ve been warned by shellcheck EDI…

I don't think aliases help in one common case listed in the article. That is, scripts run out of cron, that don't read initialization files. And that case will email on unexpected stderr writes.

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

#96

Post by kwhitefoot » Thu, Oct 13, 2022, 1:44 PM UTC

Sounds like a non-story to me. fgrep and egrep have been deprecated for nearly fifteen years and anyone who wants the old behaviour has only to create a couple of simple script files.

Any distro that wants to can easily maintain such things.

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

#97

Post by drewg123 » Thu, Oct 13, 2022, 1:45 PM UTC

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 root wheel 30736 Sep 26 14:37 /usr/bin/fgrep

281835 -r-xr-xr-x 4 root wheel 30736 Sep 26 14:37 /usr/bin/grep

281835 -r-xr-xr-x 4 root wheel 30736 Sep 26 14:37 /usr/bin/rgrep

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

#98

Post by mannykannot » Thu, Oct 13, 2022, 1:46 PM UTC

ufo wrote: post #89

mannykannot wrote: post #15

Earlier quoted context omitted.

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.

It would be even nicer to see convincing evidence that it is not going to be a problem.

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

#99

Post by iso1631 » Thu, Oct 13, 2022, 1:46 PM UTC

_jal wrote: post #60

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…

> It is legitimate to consider convenience for the maintainers In which case, time to fork it. I don't fucking care who you are, you do not break grep and keep a privileged position on my machine.

Nobody is stopping you from forking it.

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

#100

Post by Poiesis » Thu, Oct 13, 2022, 1:46 PM UTC

As a software developer, I have long-since ingrained the behavior of looking up the documentation before I assume something works in a particular way. Perhaps doubly so when shell scripting, where I have to verify if I can rely on a particular package being present, or the minimum version of something I can expect, or what the output is guaranteed to be.

When I was considering using fgrep, I looked it up; lo and behold, it's not part of the POSIX standard. So I used the option instead, and have since.

I'm a little puzzled why people have problems with these little things when it feels like it's pretty common for tools to change given enough time (for example, ifconfig and netstat to ip and ss). It's just essentially an API that gradually refines over time.