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

11–20 of 354 posts

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

#11

Post by forgotpwd16 »

Forge36 wrote: post #3

Why aren't these split into separate packages? If a distro wants to drop them, they can still be installed. If some distro wants to include them with a warning that's also fair game.

>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` and `egrep` are just `exec ${nixpkgs.gnugrep}/bin/grep -F "$@"` and `-E` respectively.

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

#12

Post by roenxi »

kevincox wrote: post #2

What problem is this warning trying to solve? Are these two symlinks too much maintenance burden? Or is the check in the code hurting the code quality? Is the extra check at startup ruining performance? I'm usually in favour of having one way to do things but in this case, with this much legacy it just doesn't seem worth it.

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 isn't going to be there and that is more than sufficient a justification.

Complaining is probably more reasonable than asking for a justification here.

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

#14

Post by tuetuopay »

airza wrote: post #10
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…

It seems pretty simple, piping bash commands into other bash commands and other text stream juggling is a pretty typical use of these commands and so changing what stream is output can change the behavior of consumers of the output of these functions. I haven’t done anything with fgrep and egrep before but piping grep into another grep for more complex classes of text search is something i use a lot.

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.

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

#15

Post by mannykannot »

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 it is in the form of constructive criticism.

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

#16

Post by jonas-w »

VWWHFSfQ wrote: post #9
thepawn1 wrote: post #4

alias fgrep='grep -F'

the issue is that programs rely on the existence of fgrep in its PATH. your shell alias doesn't fix that.

It is a bit hacky but you could put "grep -F" in a script file in your path.

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

#17

Post by forgotpwd16 »

jonas-w wrote: post #16
VWWHFSfQ wrote: post #9

Earlier quoted context omitted.

the issue is that programs rely on the existence of fgrep in its PATH. your shell alias doesn't fix that.

It is a bit hacky but you could put "grep -F" in a script file in your path.

That's what GNU grep recommends: https://www.gnu.org/software/grep/manual/html_node/Usage.htm...

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

#18

Post by mannykannot »

tuetuopay wrote: post #14
airza wrote: post #10

Earlier quoted context omitted.

It seems pretty simple, piping bash commands into other bash commands and other text stream juggling is a pretty typical use of these commands and so changing what stream is output can change the behavior of consumers of the output of these functions. I haven’t done anything with fgrep and egrep before but piping grep into another grep for more complex classes of text search is something i use a lot.

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.)
Post reply on HN