61–70 of 354 posts
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?
shopt -s expand_aliasesEarlier 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.
When was that? For as long as I can recall, a core mantra of free/libre software has been that it was provided "AS IS" without warranty of any kind. Decades ago the dominant response I recall was one of gratitude and a little amazement that ad-hoc communities of volunteers were making real software that wasn't just academic but on par with commercial offerings. Some of those communities chose to adopt a user-friendly posture because they wanted people to like them but plenty did not and just did their own thing. As long as they could attract contributors they kept going.
Personally what concerns me is this growing expectation that volunteering to maintain an open source project also means you are "morally or ethically beholden or responsible" to anyone who uses it. In practice that seems to mean maintainers must respond to user requests or end up on the receiving end of a great deal of vitriol. It's no wonder so many volunteer maintainers who have internalized this responsibility are burning out, and how many more potential maintainers are dissuaded by seeing what is happening to the current maintainers.
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…
It can't be that much work to maintain a symlink. The idea that it could be less work to remove a standard feature that has been part of Unix for several decades, has no connection with reality. There is no reasonable explanation for this decision except that somebody thought that having both egrep and grep -E was "ugly" according to their own personal sensibilities.
E.g. I can't count the number of times I have submitted _the_ _same_ _GUI_ _fixes_ to certain popular browser over the decades. Because apparently "they" have to rewrite the chrome of the mobile version from scratch every handful of years. "They" is in quotes because it's, in fairness, never the same person or even the same group of people. It's a CADT.
And in this case, to remove what apparently are two small shell scripts which for sure cost more to remove than to preserve....
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…
> On the first point the author only gives hypothetical examples I have scripts everywhere , some of them 20 years old or more, that use fgrep. For years and years it was a "best practice" thing if you were checking for a fixed string (so that you didn't accidentally match on a "." or whatever by forgetting it was a regex).
Any of these options seem reasonable to me.
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.
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.
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.
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.
Should we do better? Absolutely! Will this burn people if vendors don’t take care? Also absolutely!
Earlier quoted context omitted.
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…
Quoted post unavailable.
But like I already said in my previous comment, I wouldn't have made this change myself. I actually strongly disagree with it. But I can also accept that other people have a different attitude, and that's okay too, even if I personally don't really care much for the particular attitude.
Funny you mention OpenBSD, because OpenBSD is very much "by the developers, for the developers" and has a fairly decent "fuck off" attitude once people start making demands (which I don't think is a negative per se).
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…
We shouldn't change the oldest parts of our OSes without a really good reason.