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

201–210 of 354 posts

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

#201

Post by brundolf »

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…

Why wouldn't they just convert them to aliases instead of adding the warnings?

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

#202

Post by teddyh »

ajross wrote: post #178
teddyh wrote: post #168

Earlier quoted context omitted.

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.

That wasn't my take. I thought we were discussing the deprecation itself. It's true that nothing is broken yet[1]. But it's clear that "broken" is where we're going, and I don't think you or the GNU maintainers have thought through the implications correctly. [1] At least, nothing that isn't sensitive to junk on stderr -- bourne scripts are not always as tolerant as you'd like.

We were explicitly discussing GNU grep 3.8, which does not remove anything, only add warnings. And the remote possibility of breakage due to warnings is why I qualified my assertion with “in all likelihood”.

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

#203

Post by teddyh »

mannykannot wrote: post #98
ufo wrote: post #89

Earlier quoted context omitted.

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.

You can’t prove a negative.

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

#204

Post by hnlmorg »

brundolf wrote: post #201
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…

Why wouldn't they just convert them to aliases instead of adding the warnings?

aliases aren't a global state. They're shell and profile specific (as there are plenty of instances where a profile isn't loaded).

With `egrep` defined as a shell script, any process (even callers who are not shells) will have the same behavior.

That doesn't mean the shell script is the best solution though. Personally I'd rather they be a symlink to `grep` and have grep check the name it's been invoked as, and if it's "egrep" (or "e" if you're just checking the first byte) then implicitly enable the -E flag. This is how FreeBSD works and it feels like a more elegant solution in my opinion.

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

#205

Post by acdha »

markstos wrote: post #198
acdha wrote: post #171

Earlier quoted context omitted.

I find this reasoning interesting since it's why I _stopped_ using egrep/fgrep around the turn of the century: because those aren't standard, it wasn't uncommon to find that you depended on some behaviour which wasn't available in the version installed on some random server but it worked when you used grep.

I don't remember why I stopped using the shorter `egrep` and only use `grep -E`, but I suspect this was the reason. I used to work on a variety of BSD and Linux servers. I'm fine with this clean-up and simplification. Eventually, there will be more future users of `grep` than past users.

Yeah, I worked with enough older systems (SunOS, Solaris, AIX, HPUX, FreeBSD/NetBSD/OpenBSD, etc.) that I don't remember which ones caused me to do that, either. I'm really glad it's no longer common to have things like hand-compiled installs of GNU utilities, especially since not every sysadmin was diligent about updating all of them.

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

#206

Post by forgotpwd16 »

ksherlock wrote: post #38
forgotpwd16 wrote: post #11

Earlier quoted context omitted.

>Why aren't these split into separate packages? Because they're the same thing. What all is about are the `xgrep` commands being symlinks to `grep`. Though I guess you can have packages that just add the symlink. >If some distro wants to include them with a warning that's also fair game. Some distros already do what is recommended in release notes. Rather being symlinks they're wrapper scripts. E.g. in Nix the `fgrep…

GNU egrep and fgrep are wrapper scripts (and have been for 10 years for more). Wrapper scripts that now warn you not to use them. https://git.savannah.gnu.org/cgit/grep.git/tree/src/egrep.sh

True, the symlink part is wrong. Guess I should've checked the code. But in similar vein, a distro can just have packages adding the scripts.

edit: But was not always wrong. Just terribly outdated. Searching the log I found the commit [5cb71b0] with the message:

  Add patch from
  Paul Eggert  to comply with ridiculous
  guidelines (don't act differently if invoked as egrep or fgrep)
which made the change from creating symlinks to creating scripts. The code continued to adjust behavior according filename (in contrast to what someone would expect based on the commit message). Then few years afterwards in [d25bebd] the scripts and the symlink behavior were dropped for actual binaries, with in-source comment:

  /* We build specialized legacy "egrep" and "fgrep" programs.
     No program adjusts its behavior according to its argv[0].
     No scripts are provided as an alternative.  Distributors
     are free to do otherwise, but it is their burden to do so.  */
It also funnily added the following prints, quite similar to what they're doing now:

  Invocation as `egrep' is deprecated; use `grep -E' instead.

  Invocation as `fgrep' is deprecated; use `grep -F' instead.
The scripts returned about a decade later (or else few years ago) in [b639643]. The commit message mentioned the reasoning:

  Although egrep's and fgrep's switch from shell scripts to
  executables may have made sense in 2005, it complicated
  maintenance and recently has caused subtle performance bugs.
  Go back to the old way of doing things, as it's simpler and more
  easily separated from the mainstream implementation.  This should
  be good enough nowadays, as POSIX has withdrawn egrep/fgrep and
  portable applications should be using -E/-F anyway.
[5cb71b0]: https://git.savannah.gnu.org/cgit/grep.git/commit/?id=5cb71b...

[d25bebd]: https://git.savannah.gnu.org/cgit/grep.git/commit/?id=d25beb...

[b639643]: https://git.savannah.gnu.org/cgit/grep.git/commit/?id=b63964...

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

#207

Post by jeroenhd »

kentonv wrote: post #162

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

If the GNU folks want to remove the wrapper scripts, they can. It's their software and they write the best practices for it.

Distro maintainers can still ship these scripts. They can add aliases to the user profile to do the same thing without having to launch a sh instance. Maybe they'll add a second package, grep-utils, that just contains the wrapper scripts so you can choose between GNU's position and the "I don't like change" position.

Microsoft has deprecated and removed tons of stuff and so did browsers. Vista crashed so often because Microsoft did away with their entire driver model and vendors wrote quick wrappers around their old, crappy drivers and shipped those. Many remaining browser features are reasons why web development sucks so much ("quirks mode" for one) and Java not breaking compatibility has given it many problems that dotnet solved by breaking compat once. Java also has removed several deprecated packages and moved them to libraries instead (like Nashorn).

Deprecated means "if we see a reason to remove this, we may remove this in the future". It's no guarantee for removal but it's no guarantee for being kept around either.

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

#208

Post by thayne »

gatonegro wrote: post #180
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…

> I'd be surprised if that warning made its way to the mainstream distros. This is the first time I'm hearing about the warning, but I thought I'd run `egrep` and `fgrep` on my Arch system. Sure enough, both result in warnings: `egrep: warning: egrep/fgrep is obsolescent; using grep -E/-F` So it's made its way into Arch, at least. Though, like I said, this is the first time I'm hearing about this.

I use arch, and I had an alias for grep to expand to `egrep --color=always` in my interactive shell. I noticed real fast. Fortunately it's an easy fix to `grep -E --color=always`.

sidenote: I wish that grep would allow running `grep -E -F`, and have the `-F` flag override the `-E` flag, rather than giving an error about conflicting options, so that I could have an alias like this to make extended regex the default, but allow me to change it with a flag.

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

#209

Post by forgotpwd16 »

yubiox wrote: post #193
Beltalowda wrote: post #123

Earlier quoted context omitted.

I don't think grep does any argv-stuff; I took a quick look and I don't see it. As far as I can tell this is the entire maintenance burden: $ cat =egrep =fgrep #!/bin/sh exec grep -E "$@" #!/bin/sh exec grep -F "$@"

what shell does this?

Apparently zsh replaces =cmd with cmd's absolute path. TIL.

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

#210

Post by Communitivity »

adren67 wrote: post #192
cies wrote: post #165

I'm on ripgrep (Rust, very fast). Thanks BurntSushi!

I completely agree that rg/ripgrep is a way better alternative to most grep implementations including GNU grep not only in terms of feature check https://beyondgrep.com/feature-comparison/ for a detailed comparison but also in terms of speed, including the fact that ripgrep allows greping by default in compress files, many different encoding and more! This software is really a must-have for anyone who spends some tim…

I also use ripgrep, and swear by it. It has many of the features previously only found in ag or git grep (parallelism, respect .ignore files, search hidden files, etc).

It's old, but here'd a feature comparison of ag, git grep, ripgrep and others:

https://beyondgrep.com/feature-comparison/

Post reply on HN