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

221–230 of 354 posts

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

#221

Post by ilc »

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 went over to Nix cold turkey for my new work laptop. Took about a week or two, to get it where I wanted it. The real issue I hit is that Nix is so alien to working with "normal" unix stuff... like stuff that assumes /usr/bin/grep exists etc, I had issues, with the existing code-base I was hired to work on.

So, I went back to Fedora. But I'd goto Nix again in a heartbeat. It is a great system, and if you start a company with it day 1... there will be a bit of heartburn as you start, but I can't see regretting it.

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

#222

Post by im3w1l »

grnmamba wrote: post #148
im3w1l wrote: post #101

Yet another reason why shellscripts are bad huh.

How does the article lead to this conclusion?

People are upset that changing literally anything on the system like adding a deprecation warning to stderr will break their fragile shellscript setup.

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

#223

Post by thebeardisred »

NegativeLatency wrote: post #217
thayne wrote: post #208

Earlier quoted context omitted.

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, b…

You could write a little function that does that

For me, that's the biggest takeaway:

Nothing is stopping users from maintaining the behavior they had previously.

It's being made explicit that the burden of maintaining that behavior is changing.

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

#224

Post by [deleted] »

yjftsjthsd-h wrote: post #212
aftbit wrote: post #138

On my system, egrep and fgrep are _already_ shell scripts, just changed to add the stupid warning: $ cat =egrep =fgrep #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -E" >&2 exec grep -E "$@" #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -F" >&2 exec grep -F "$@" Looking at src/egrep.sh in the git repo[1], I see that before this warning was added in 2021, the…

> cat =egrep =fgrep What is that? I can't seem to find it by searching for " =" in `man bash`

[deleted]

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

#225

Post by hnlmorg »

jomar wrote: post #174
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 too was surprised to see these were shell scripts. I was expecting the grep/fgrep/egrep names to be hard links to the same executable that would check `argv[0]`, as the BSD implementation does. More interesting than the commit diff is the brief discussion on the bug report from when this all happened a year ago, as referenced in the commit message: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996 Sigh. Time to r…

Thanks for sharing that. It was an interesting read. Particularly this comment:

> The irony... that one of our own tests used fgrep!

If ever there was an argument for fgrep becoming a pseudo-standard that should remain, that would have been it.

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

#226

Post by pwagland »

yjftsjthsd-h wrote: post #212
aftbit wrote: post #138

On my system, egrep and fgrep are _already_ shell scripts, just changed to add the stupid warning: $ cat =egrep =fgrep #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -E" >&2 exec grep -E "$@" #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -F" >&2 exec grep -F "$@" Looking at src/egrep.sh in the git repo[1], I see that before this warning was added in 2021, the…

> cat =egrep =fgrep What is that? I can't seem to find it by searching for " =" in `man bash`

This is a zsh thing, it's shorthand for:

cat "$(which egrep)" "$(which fgrep)"

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

#227

Post by kentonv »

jeroenhd wrote: post #207
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…

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

I'm not making any argument about the maintainer's rights. I am making an argument about whether it was a good technical decision.

> [people can work around it]

That doesn't make it a good idea, though.

> Microsoft has deprecated and removed tons of stuff and so did browsers.

Only when there was a real benefit deemed greater than the cost.

In this case there is essentially no benefit whatsoever to the change, except some abstract notion of cleanliness or pedantic spec compliance.

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

#228

Post by mirker »

richard_todd wrote: post #213

It's interesting to think about the way these things evolved. Imagine if, over time, the `compress` utility got -gz, -bz2, -lzma, etc. flags, and `gzip`/`bzip2` were all converted to deprecated shell scripts. When is the right time to consolidate variants under one program (and deprecate the variants), and when is it better to let small utilities keep doing one thing well(TM)? I see people talking about removing the…

As someone who learned about regular expressions before extensively using grep, I found grep to be quite unintuitive, since extended grep is what I am conceptually thinking about from a “theory” point if view. One difference between grep and compression is that grep is bounded by regular languages, but compression is more free form. It’s conceivable to therefore view grep as mature enough of a technology to be finished once and for all, but compression will continue branching into many disparate algorithms.

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

#229

Post by radford-neal »

Beyond the inadvisability of making a breaking change for no reason, it's worth noting that deprecating fgrep is actually positively undesirable. Use of fgrep should be encouraged.

The reason is that many times people want to match a literal string. This is best done with, for example, "fgrep [a] Of course, one could get in the habit of using grep -F when intending the pattern to be just a literal string. Or one could write one's own fgrep shell file. But both of these options require more effort than just using fgrep. One aim of good design should be to make it easy to do things in the reliable way. That way it's more likely to be done.

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

#230

Post by [deleted] »

yjftsjthsd-h wrote: post #212
aftbit wrote: post #138

On my system, egrep and fgrep are _already_ shell scripts, just changed to add the stupid warning: $ cat =egrep =fgrep #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -E" >&2 exec grep -E "$@" #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -F" >&2 exec grep -F "$@" Looking at src/egrep.sh in the git repo[1], I see that before this warning was added in 2021, the…

> cat =egrep =fgrep What is that? I can't seem to find it by searching for " =" in `man bash`

[deleted]
Post reply on HN