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

151–160 of 354 posts

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

#151

Post by gumby »

PaulHoule wrote: post #140
barrkel wrote: post #114

Earlier quoted context omitted.

There's a certain type of person who gets pleasure from following rules exactly, particularly when other people don't follow those rules. A kind of smug moral superiority. If they get into a position of power, they can make life worse for other people, without much regard for the actual cost of breaking such rules. Removing egrep and fgrep is desperately petty stuff.

It’s a show of how free software partisans are often out of touch. The cost of egrep and fgrep is just two symbolic links. Some people though would rather talk about ‘libre’ and ‘free as in speech’ and ‘free as in beer’ than talk at all about the user experience. And they wonder why most people just run windows or macOS, but they’ll never understand.

> The cost of egrep and fgrep is just two symbolic links.

A cost that needs to be paid every time you invoke them (a double lookup in the filesystem). Just use a regular link.

(I felt a pedantic response would be in the spirit of this change by the GNU project).

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

#152

Post by tolciho »

nickcw wrote: post #110

If you want modern regexp syntax then forget egrep/grep -E and use grep -P for Perl Compatible Regular Expressions. PCRE is the most commonly used regex syntax for modern programming languages, eg Python, Go (mostly) etc and grep -P will save lots of annoyance if you use one of these!

The -P is not for portability.

  $ grep -P foo
  grep: unknown option -- P

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

#153

Post by acdha »

blacklight wrote: post #48

While I hated the decision of adding warnings without much notice (which, in the case of such widely used CLI tools, is the equivalent of a breaking change), I also found an easy solution that would prevent my scripts from spitting out lots of unneeded warnings. alias egrep='grep -E' alias fgrep='grep -F' Now GNU developers can keep doing whatever they're doing, and I can keep doing whatever I used to do.

> While I hated the decision of adding warnings without much notice (which, in the case of such widely used CLI tools, is the equivalent of a breaking change)

15 years isn't “much notice”? I had already stopped using those back then because, as noted in the article, they weren't standardized and so you had to work about portability across Unix installations.

It's also worth noting that this is only a breaking change if you are using the non-standard names in a context where you are trapping output. For the vast majority of people using a shell script which doesn't use the common name, they will at some point upgrade, see the warning, spend 30 seconds making the change, and never think about it again. If you're that sensitive to the extra work, presumably you also do some testing before installing new upstream releases.

EDIT: it was actually 17 years ago that the warning was added about egrep/fgrep:

https://git.savannah.gnu.org/cgit/grep.git/commit/?id=0b4859...

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

#155

Post by dahart »

The article and very few comments acknowledge that this is being done to facilitate removal of these binaries. Assuming the binaries are going away, is it better to add a warning, or to surprise people be just removing them?

In general, there’s a good, legitimate, hard question here about how to handle removing things from our software. It needs to be done, probably more often than we do it, and it’s hard enough for software writers and maintainers to bring themselves to remove things. Are there better strategies? What more can we do to make removing features less painful, beyond publishing the deprecation schedule, adding a warning in advance, and then removing them after the schedule and the warning have been out for a while?

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

#157

Post by bitofhope »

cestith wrote: post #102
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…

The shell happens to be a programming tool and not just an interactive command interpreter. There are whole books on how to write shell scripts portably across various Unix-y platforms. Many of the examples in those books will now throw warnings on systems using the GNU tools.

If a book on writing portable shell scripts across *nix platforms depends on commands not specified by POSIX, I don't think those books are doing their job very well.

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

#158

Post by tomn »

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

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

#159

Post by saalweachter »

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.

At a guess, it isn't actually the symlinks, it's the argument parsing they're trying to simplify.

Old programs have stupidly complex argument parsing. If you can pass your arguments as "cmd foo bar path", "cmd -f bar path", "cmd -fbar path", "cmd path --foo=bar" or "fcmd bar path" and "cmdf path bar", it can be really convenient for users who can structure their commands in the way that makes the most sense for them.

But it can be really frustrating to maintainers who are maintaining -- and testing! -- a thousand lines of bespoke argument parsing for a ten line function.

It's really, really tempting to define a simple syntax for argument parsing, turn it into a library, and reduce your pile of shell commands to a few lines of argument configuration and a function call.

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

#160

Post by chriswarbo »

mcv wrote: post #72
thomascgalvin wrote: post #56

Earlier quoted context omitted.

> 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. It's a bit old now, but one of the principles of Twelve Factor Applications is to vendor-in all of your dependencies.[1] > A twelve-factor app never relies on implicit existence of system-wide packages. It declares all dependencies, completely and exactly, via a dependency declara…

You're protected, but it also means you can never upgrade anything. An application can never know what future versions of a dependency it can work with (because a new version might contain a breaking change), so it will always require versions that existed at the time of its own creation. But those versions might contain vulnerabilities, and the new version might fix those while being fully compatible in every other…

> You're protected, but it also means you can never upgrade anything.

No, it just means that:

- Upgrading a dependency is a change, which should be treated like a code change (review, testing, etc.). I stated as much above.

- If, for some reason, you're stuck using an old version, that only affects the relevant part of the system. For example, scripts which rely on some old behaviour can remain pinned to that version; whilst other parts of the system can use an upgraded dependency. Also, just as importantly, parts of the system which don't need something (like grep) have no access to any version of it.

Post reply on HN