21–30 of 354 posts
> The egrep and fgrep commands have been deprecated since 2007. Isn't 15 years more than enough time to handle the deprecation?
I’m just joking :)
> The egrep and fgrep commands have been deprecated since 2007. Isn't 15 years more than enough time to handle the deprecation?
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…
Yes, but the convenience of... creating 2 symlinks and adding the flag based on argv[0]?
Sorry, I don't buy it. Wanting to die on such a tiny hill has GNU written all over it though
Does the warning go to stdout or somewhere else?
Earlier quoted context omitted.
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.)
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…
At least we used to pay lip service to that ideal.
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.
#!/bin/sh exec grep -E "$@"
- Thousands of users have to update their scripts, habits, shell configs; or
- The GNU Grep maintainers spend essentially zero minutes "maintaining" a few lines of code to automatically use -E or -F based on argv[0].
It seems to me the second is obviously the better option.
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.
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.
That said, I certainly wouldn't have put in this change myself, because I wouldn't like to inconvenience anyone. But that's just basic good manners that you should have in every-day life to random strangers.
> The egrep and fgrep commands have been deprecated since 2007. Isn't 15 years more than enough time to handle the deprecation?
https://medium.com/@rualthanzauva/grep-was-a-private-command...
What actually happened here is that POSIX skipped it. It never entered a standard, even though it was (literally!) in every OS and available to everyone. But no one cared that it wasn't in some arbitrary standard, because it was always there. For half a century!
I dare say that "fgrep" and "egrep" have more active users (both interactive and scripted) than "awk" or "ed" or "od" or "bc", all of which are still around.