This reminds me of the last time daylight savings time was changed (in the US). A bunch of hassle and software breakage.. for what? Just to get back to the same place we already were (working software)? What a waste.
We are stuck with egrep and fgrep (unless you like beating people)
41–50 of 354 posts
Re: We are stuck with egrep and fgrep (unless you like beating people)
#42> 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".
There is so much outdated info on the internet in various forms that it is hard even to realize what is "proper modern way" of doing things unless you really are into Linux \ config stuff.
I am casual user so I can get around system but modern ways always surprise me when I finally find out about it.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#43Earlier 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.
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
Re: We are stuck with egrep and fgrep (unless you like beating people)
#44Re: We are stuck with egrep and fgrep (unless you like beating people)
#45What 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.
Unfortunately, this seems symptomatic of GNU's attitude: we've come up with something silly and it's going to screw some people over badly in the least agreeable moment, but we're too stubborn and proud to admit it. Take it, or buy a Windows 11 license.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#46[deleted]
Re: We are stuck with egrep and fgrep (unless you like beating people)
#47I think it's a bit silly to get rid of such established aliases. Surely they aren't a real maintenance burden.
Though I can't say I entirely hate it, for the (admittedly absurd) reason that egrep = grep -E, fgrep = grep -F, but pgrep != grep -P! It's an awkward incongruity that's easy to get tripped up on occasionally.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#48While 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.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#49Earlier 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.
Wouldn't you test before upgrading packages in production? And usually you'd want to schedule any upgrades so that the next day or two has coverage from someone who can deal with any issues that arise.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#50I 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…
Both of your suggestions are basically equivalent to "think before you upgrade" and/or "don't upgrade". This is the second elephant in the room with all these distros that "don't use globals" and/or statically link everything (or do an analogue to that, like nix). There's very little benefit for desktops. So the upgrade to dependency X breaks component Y, and you are forced not to update X, or at least, Y's copy of X. Great. What do you do now? Swim away from upstream? Stay on outdated components? The situation is as unatenable long-term as it is on a regular distro...
The first elephant in the room is that generally you _do_ want most dependencies to be global state. Is a situation where every program is using its own version of the graphics toolkit, with different theming issues or even different themes altogether, really ideal for a desktop situation? What about libevent -- so that your mouse's wheel has one acceleration curve in some programs and some other speed in some other programs ? Or what about ibus, where generally having different client versions running simultaneously means your entire input system stops working ?
Even grep is likely something that you'd prefer to be global state, lest the grep exec() by a Python interpreter have different features than the one launched by your main shell.