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

161–170 of 354 posts

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

#161

Post by koprulusector »

ur-whale wrote: post #130
koprulusector wrote: post #103

Earlier quoted context omitted.

Frankly I can count on two hands the number of times I’ve used egrep in my life (same for grep -E). As long as I can remember I’ve relied on sed, awk, or find -regex for filtering output with regex. I only say this because I can’t relate to those that are upset about the change. That said, to answer your questions directly: hopefully you aren’t auto updating anywhere in production or important, so this won’t effect a…

> Frankly I can count on two hands Emphasis on "I", which says strictly nothing of the rest of CLI users out there. We're very glad to learn that it is not a problem for you , but it brings very little to the conversation.

But neither does this comment.. do you have an example to share in response to my questions above?

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

#162

Post by kentonv »

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

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

#163

Post by koprulusector »

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…

Thanks for sharing. I feel less silly for suggesting this now (as root):

    unalias grep && unalias egrep && cp "$(command -v grep)" "$(dirname "$(command -v grep)")/egrep

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

#164

Post by bitofhope »

Pxtl wrote: post #94

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.

You can technically pipe to streams other than &1 and &2, so you could use

  printf "WARNING: %s" "$warn_msg" >&3
But of course, nonstandard.

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

#166

Post by tannhaeuser »

hnlmorg wrote: post #146

There seems to be a lot of confusion in this discussion about what the change is and how egrep and fgrep work. These are not symlinks like some have suggested but rather shell scripts. You can see the exact commit diff here: https://git.savannah.gnu.org/gitweb/?p=grep.git;a=blobdiff;f... I remember around ~10 years ago being told "you should never use `egrep` because it is slower than `grep -E`." precisely because th…

When it comes to avoiding forks, the question is why do egrep, fgrep have to be shell scripts rather than interpret the invocation name (argv[0]) for switching behavior. Also, I find the original POSIX spec to lump everything into a single grep binary questionable since egrep, fgrep developed as extension and restriction, resp. of grep under a classic regexp discourse and it isn't clear at all that automaton construction for powerful egrep support has to live in the same binary as fgrep which isn't using automaton construction at all.

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

#167

Post by radford-neal »

thomastjeffery wrote: post #149
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…

I find it amusing that someone who uses fgrep all the time - and is presumably familiar with alias and sed - would be worried about the inconvenience of updating their shell scripts... I think the larger issue is that people generally don't do dependency management for their scripts. Scripts are programs, and they are dependent on the shell environments they are written for.

I think you're not grasping the point that the cost of using 'alias' or updating scripts, though not huge, is paid by every single user, and often over and over again, every time they switch to using a different system. Against this cost for every user, one weighs the benefits of this change - which are zero. Indeed, the benefits are negative, since the maintainers must surely be wasting more time debating the change than they will ever save from it.

Of course, scripts are dependent on their environment. That's why changing the environment for no reason is such a bad idea. Nobody manages their shell scripts to account for the possibility that 'true' might cease to exist some day...

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

#168

Post by teddyh »

simoncion wrote: post #129
teddyh wrote: post #112

Earlier quoted context omitted.

Either a system is frozen and static, in which case it will not receive this version of GNU grep, and there is no problem. On the other hand, if a system receives updates, the system needs both minor and major changes all the time , to keep up with its ever-changing environment. This is the jungle in which we live. Linux syscalls are important to keep, since it’s hard to change a compiled binary. But it’s easy to cha…

> This won’t, in all likelihood, “break” your scripts. Previously: > 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. script.sh: line 100: fgrep: command not found seems like evidence of a broken script to me. The fact that it can be fixed doesn't make i…

We were discussing the warning printed by fgrep and egrep, not their removal. I was suggesting that you put a version of fgrep/egrep in your path which does not show the warning.

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

#169

Post by hnlmorg »

tomn wrote: post #158
hnlmorg wrote: post #146

There seems to be a lot of confusion in this discussion about what the change is and how egrep and fgrep work. These are not symlinks like some have suggested but rather shell scripts. You can see the exact commit diff here: https://git.savannah.gnu.org/gitweb/?p=grep.git;a=blobdiff;f... I remember around ~10 years ago being told "you should never use `egrep` because it is slower than `grep -E`." precisely because th…

the overhead isn't even an extra fork, as it uses exec

Good point. Though invoking $SHELL and parsing the script (as short as it is) can't be cheap either. Academically speaking of course; I'm not trying to justify the change on performance grounds.

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

#170

Post by chrismarlow9 »

I started to get really passionately angry about this because I am an fgrep user. Then I realized I can avoid my blood pressure spiking by just running a one liner and making a few edits. The muscle memory might take a while to fix but I'll be better for it and avoid my day starting off with anger about trivial things.

sudo grep -rF 'fgrep' / 2>fgrep.rip.stderr.log | tee fgrep.rip.log

Goodbye old friend...

Post reply on HN