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

51–60 of 354 posts

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

#51

Post by SkyBelow »

Ensorceled wrote: post #26
roenxi wrote: post #12

Earlier quoted context omitted.

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…

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.

One major issue with humans is that sacrifice begins to be expected and often is not rewarded. When a job not only becomes thankless, or near enough, but also expected as the default, it becomes hurtful to continue doing it.

Are the stewards being provided fair compensation? How do we even talk about what is fair compensation when non-monetary compensation has become difficult to even discuss (often due to past instances being extreme disproportionate or of a form that is no longer tolerable).

The simplest way to put it is that if you can't find a steward you aren't paying enough and trying to use appeals to morals or ethics to get people to accept lower pay no longer holds as much weight when being moral or ethical no longer provides the same level of non-monetary benefits.

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

#52

Post by ourmandave »

Tangentially, I'm still searching for a grep for Windows you can run from file explorer.

I've resorted to right-clicking a command window and using findstr. =(

I'm sure there's also a powershell equiv but I haven't taken the time to walk the PS object tree to find it.

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

#53

Post by guhidalg »

mannykannot wrote: post #33
loloquwowndueo wrote: post #25

Earlier quoted context omitted.

But if you’re monitoring the output it usually means you are in a position to fix problems which means you can likely update the script in question to use the new warning-less invocation.

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.

I don't know if I have sympathy for this argument.

Your script ostensibly handles (at least logs) errors and warnings right? Do you exhaustively handle every single error and warning in a unique and different way or do you have a catchall "If non-0 return code then fail"? How does introducing new output to stderr affect that?

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

#54

Post by P5fRxh5kUvp2th »

mannykannot wrote: post #33
loloquwowndueo wrote: post #25

Earlier quoted context omitted.

But if you’re monitoring the output it usually means you are in a position to fix problems which means you can likely update the script in question to use the new warning-less invocation.

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.

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

#55

Post by misnome »

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.

Your scripts expand aliases?

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

#56

Post by thomascgalvin »

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 declaration manifest. Furthermore, it uses a dependency isolation tool during execution to ensure that no implicit dependencies “leak in” from the surrounding system. The full and explicit dependency specification is applied uniformly to both production and development.

This scenario, with `fgrep` and `egrep` releasing a potentially breaking change, is exactly why this principle exists. If your software depends on "whatever fgrep happens to be lying around at the moment", your application might break the next time you build and deploy a new image. If you're pinned to a specific version, however, you're protected.

[1] https://12factor.net/dependencies

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

#57

Post by gw99 »

Beltalowda wrote: post #22
xpressvideoz wrote: post #5

> The egrep and fgrep commands have been deprecated since 2007. Isn't 15 years more than enough time to handle the deprecation?

I betcha most people didn't even know they were considered "deprecated".

Yes. This is the first I've heard of it and I've got a ton of scripts that are probably going to break.

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

#58

Post by koprulusector »

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

EDIT2: here’s another one liner with one caveat being updates (also needs to be run as root)

    # unalias grep && unalias egrep && cp "$(command -v grep)" "$(dirname "$(command -v grep)")/egrep"
EDIT3: just realized for most this will only ever come up in scripts because many distros already add alias egrep='grep -E' to your shell aliases (~/.bash_aliases, ~/.zshrc, etc). Thus you may only need the shopt -s expand_aliases.

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

#59

Post by LinuxBender »

Beltalowda wrote: post #22
xpressvideoz wrote: post #5

> The egrep and fgrep commands have been deprecated since 2007. Isn't 15 years more than enough time to handle the deprecation?

I betcha most people didn't even know they were considered "deprecated".

I learned about the deprecation from ShellCheck [1] that warns if using egrep instead of `grep -E`. That tool deprogrammed many of my bad habits. I had never seen any discussions about it otherwise.

[1] - https://www.shellcheck.net/

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

#60

Post by _jal »

roenxi wrote: post #12
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…

> It is legitimate to consider convenience for the maintainers

In which case, time to fork it.

I don't fucking care who you are, you do not break grep and keep a privileged position on my machine.

Post reply on HN