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

71–80 of 354 posts

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

#71

Post by ComputerGuru »

koprulusector wrote: post #58

I’ve been using grep -E for a long time, I thought I remember it being from a warning from egrep or something.. can’t really remember for sure, though. Either way, I don’t see what the big deal is, just add an alias egrep='grep -E' If you’re worried about your non-interactive shell scripts, shopt -s expand_aliases; alias egrep='grep -E' and you can move on with your life. EDIT: I must’ve been warned by shellcheck EDI…

It’s a matter of principle. If you wrote a script yesterday (or a year ago) and didn’t include that line, you need to re-release it today. That’s stupid.

Also, you’re being very sanctimonious about this but what if you didn’t see this HN story. Would you know to do that for the next script you distribute?

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

#72

Post by mcv »

thomascgalvin wrote: post #56
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…

> 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 way, in which case you really do want the upgrade.

Those dependencies should really declare when they change existing behaviour of the previous versions, and only then should your application refuse the upgrade.

No idea if there is a system that works that way; I can imagine it could get hideously complex.

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

#73

Post by mannykannot »

P5fRxh5kUvp2th wrote: post #54
mannykannot wrote: post #33

Earlier quoted context omitted.

If I had been woken up in the middle of the night or had a vacation interrupted on account of this, I would not be entertaining warm and grateful thoughts toward whoever thought it was a good idea.

If you're being woken in the middle of the night over this then your testing infrastructure is crap. This is something that should be caught before it gets to that point SPECIFICALLY so you aren't getting woken up in the middle of the night.

All the replies so far are missing the point: it is prudent to monitor for unusual events, including previously-unseen messages, over and above the explicit handling of specific errors. It is also prudent to not wait until morning to investigate.

Your infrastructure probably is crap, as very few people get to build it themselves from scratch. That does not mean one should cheerfully accept additional unnecessary or pedantic complications.

It would also be prudent to investigate each and every change to any of the software you use, in order to anticipate problems, but unnecessary and pedantic changes increase the burden there, as well.

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

#74

Post by koprulusector »

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.

Can confirm:

    $ egrep '.'  /dev/null
    egrep: warning: egrep is obsolescent; using grep -E

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

#76

Post by sillysaurusx »

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

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

#78

Post by deeblering4 »

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…

Or...

And I'm going out on a limb here...

Don't support user hostile maintainers who force breaking changes to a decades old API just because they felt like it.

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

#79

Post by Ensorceled »

Beltalowda wrote: post #29
Ensorceled wrote: post #26

Earlier quoted context omitted.

I don't know when society in general just said "Fuck It" to the idea of stewardship; but we now have it ingrained that people in positions of trust and power (whether volunteered, elected or appointed) are not morally or ethically beholden or responsible to the communities they have taken it upon themselves to represent. At least we used to pay lip service to that ideal.

They didn't necessarily "choose communities to represent". As the maintainer and author of various open source libraries and tools that are used by many thousands, in most cases it's just that ... I'm one of the few willing to spend the time on it, and it's usually useful for myself as well. I don't really "represent" any community or anyone. That said, I certainly wouldn't have put in this change myself, because I w…

That's a very different thing than joining GNU. If your package gets adopted by thousands of peoples that's having this community thrust upon you.

I still feel you have an obligation to transfer to someone willing to shoulder the responsibility if this happens, an obligation incurred by publishing it in the first place.

Though, I don't feel too strongly about this.

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

#80

Post by Ensorceled »

__s wrote: post #43
Ensorceled wrote: post #26

Earlier quoted context omitted.

I don't know when society in general just said "Fuck It" to the idea of stewardship; but we now have it ingrained that people in positions of trust and power (whether volunteered, elected or appointed) are not morally or ethically beholden or responsible to the communities they have taken it upon themselves to represent. At least we used to pay lip service to that ideal.

Are you suggesting that a 15 year deprecation path is a fuck it attitude towards stewardship? Distros are free to've replaced the symlinks with wrapper scripts in the meantime. Granted, I expect Arch will go ahead & let the symlinks disappear. But I can't imagine what you think of Arch's stewardship I expect this should have about as little impact as the usr merge many distros have gone through

I'm replying to the attitude in the comment I'm replying to, if I meant this as a comment on GNU's approach to fgrep/egrep, it would have been top level.

The original deprecation seems ... petty? Not sure why it's a priority, but whatever.

I know there are scripts still in use that I wrote more than a decade ago that might do weird things now and I wish the maintainers best of luck.

Post reply on HN