Hmmm, perhaps "a program's output is part of its interface" wasn't such a good idea after all...
If programs communicated with each other using structured interfaces and not "plain text" (already a misnomer), this would be a non-issue.
We are stuck with egrep and fgrep (unless you like beating people)
261–270 of 354 posts
Re: We are stuck with egrep and fgrep (unless you like beating people)
#262Earlier quoted context omitted.
> Frankly I can count on two hands Emphasis on "I", which says strictly nothing of the rest of CLI users out there. We're very glad to learn that it is not a problem for you , but it brings very little to the conversation.
But neither does this comment.. do you have an example to share in response to my questions above?
Everyone has their own story, and one’s person’s experience can be very different from another person’s experience. I used egrep a whole lot, dozens of times for the automated test setup I have for my open source project. I had to spend most of an hour this morning updating that code to no longer use egrep—a non-trivial task. Here’s the amount of hassle breaking egrep has given me:
https://github.com/samboy/MaraDNS/commit/afc9d1800f3a641bdf1...
This is just one open source project. I’ve seen fgrep in use for well over 25 years, back on the SunOS boxes we used at the time. egrep apparently has been around for a very long time too. Just because it didn’t get enshrined in a Posix document—OK, according to Paul Eggert it was made obsolete by Posix in 1992, but apparently no one got the telegram and it’s been a part of Linux since the beginning and is also a part of busybox—doesn’t mean it’s something which should be removed.
I’m just glad I caught this thread and was able to “update” my code.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#263Earlier quoted context omitted.
The gnu coding standards has this to say: https://www.gnu.org/prep/standards/standards.html#index-beha... Please don’t make the behavior of a utility depend on the name used to invoke it. It is useful sometimes to make a link to a utility with a different name, and that should not change what it does. The next section provides some reasoning: Providing valid information in argv[0] is a convention, not guaranteed. Wel…
Different behavior based on argv[0] was first brought to my attention when I discovered that /bin/sh was a symlink on some Linux systems. Bash has a Bourne shell compatibility mode.
Bash actually has a POSIX compatibility mode.
There is a great deal in POSIX that was not in Bourne, native arithmetic expressions being the first to come to mind, then new-style command substitution.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
All of the POSIX utility standards, including the grep variants, can be found in the URL's parent directory:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/
If this new GNU grep functionality becomes widely distasteful, I think that OpenBSD's grep tries to emulate GNU in a few ways, and could supplant it, becoming the system grep while "gnugrep" is relegated to the shadows.
It is also extremely expensive on Windows for a version of grep to be implemented as a shell script. Launched by xargs, the penalty will be severe.
The commercial platforms based upon GNU are in a marriage of convenience, and can easily pick and choose.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#264Earlier quoted context omitted.
> This reasoning is flawed. I wasn't making any reasoning. I was just making the observation that this change has been staged for a while now and that I'm surprised there hasn't been more noise about it before now. > don’t expect a flood of complaints to be time correlated with the change. I expect complaints to be correlated with whenever a blog/tweet/whatever moaning about the change happens to trend. I don't think…
> I was just making the observation that this change has been staged for a while now “There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you…
> Again, you're completely missing the point of the comment you're replying to
Actually you and the GP are the ones missing my point by obsessing over a throwaway comment about this commit being over a year old. I was literally making zero conclusions from that observation. You guys are reading far far far too much into that comment. You seem to be projecting your annoyance about this change onto me as if I’m defending and supporting this change, yet literally nothing I’ve posted has supported that claim.
> average users don't pay attention to what's being staged upstream.
I’m going to assume that you skipped over my point about how any outrage will come from blog/Twitter/etc posts going viral.
This has already landed on some distros and most people, rightly or wrongly, went “meh”. If that last 30 years of the internet has taught me anything, it’s that people get outraged by posts, not by software. And the fact that youre arguing over a meta-point like when people will get annoyed, rather than discussing the technology itself, really just confirms my 3 decades of observations.
In fact the only reason we are discussing this now is because someone blogged about it and it hasn’t even hit the distro they’re using; they know about it because they read another news article who found out about it from the release notes posted on the mailing list and the authors then went back and checked the commits! Literally nothing in that chain of discovery was via experiencing the change itself in their chosen distros.
So to be clear:
I am NOT suggesting that the commit being > 1 year old means GNU have a free pass to make a breaking change. Any conclusion like that you derive from my posts are a misinterpretation and not worth arguing over.
Now, can we move on to more interesting things?
Re: We are stuck with egrep and fgrep (unless you like beating people)
#265Earlier quoted context omitted.
> When it comes to avoiding forks, the question is why do egrep, fgrep have to be shell scripts rather than interpret the invocation name (argv[0]) for switching behavior. I don't know. I'd have taken the argv[0] approach personally. And it's the approach some other grep implementations have taken too (eg https://github.com/freebsd/freebsd-src/blob/main/usr.bin/gre... ). The argv[0] approach (to me) feels like a righ…
Switching behavior according to argv[0] been used in Unix for decades. mv(1)/ln(1)/cp(1) historically are the same program, hardlinked.
Wasn’t rm also the same?
I vaguely recall it being little more than ‘mv $1 /dev/null’ under the hood. But this might be something I’m misremembering.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#266There seems to be a lot of confusion in this discussion about what the change is and how egrep and fgrep work. These are not symlinks like some have suggested but rather shell scripts. You can see the exact commit diff here: https://git.savannah.gnu.org/gitweb/?p=grep.git;a=blobdiff;f... I remember around ~10 years ago being told "you should never use `egrep` because it is slower than `grep -E`." precisely because th…
the overhead isn't even an extra fork, as it uses exec
On most context involving "using grep", shell scripts, interactive shell, etc, it's nothing.
81 Vs 128 system calls on my laptop (just printing --version)
$ strace -fc grep -E --version 2>&1 | tail -1
100.00 0.000000 0 81 3 total
$ strace -fc egrep --version 2>&1 | tail -1
100.00 0.000000 0 128 6 total
Most situations where it could be being used, probably are surrounded by much bigger optimizations to work on.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#267I got this obnoxious whine from egrep on FreeBSD after my latest update. This post made me look, and I had gnu grep install as a dependency for something. Once I removed it, sanity is back and the built-in BSD egrep doesn't whine. On FreeBSD, they are all the same: $ ls -li /usr/bin/egrep /usr/bin/fgrep /usr/bin/grep /usr/bin/rgrep 281835 -r-xr-xr-x 4 root wheel 30736 Sep 26 14:37 /usr/bin/egrep 281835 -r-xr-xr-x 4 r…
FWIW, I have no interest in making a similar change to bsdgrep and I can't imagine anyone else would be compelled to bother, either. I just don't see the value in removing these historical names that makes the hassle worth it.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#268I use fgrep all the time. Why should I spend time converting scripts, and retraining my fingers, and forever after taking longer to type grep -F? This is a breaking change that has no upside, only downside. It is idiocy. Just to elaborate, there must be many thousands (hundreds of thousands? millions?) of shell scripts out there that use fgrep. For no reason at all (whatever maintenance burden fgrep represents must b…
[deleted]
Re: We are stuck with egrep and fgrep (unless you like beating people)
#269Earlier quoted context omitted.
I find it amusing that someone who uses fgrep all the time - and is presumably familiar with alias and sed - would be worried about the inconvenience of updating their shell scripts... I think the larger issue is that people generally don't do dependency management for their scripts. Scripts are programs, and they are dependent on the shell environments they are written for.
I think you're not grasping the point that the cost of using 'alias' or updating scripts, though not huge, is paid by every single user , and often over and over again, every time they switch to using a different system. Against this cost for every user, one weighs the benefits of this change - which are zero . Indeed, the benefits are negative, since the maintainers must surely be wasting more time debating the chan…
> the cost of using 'alias' or updating scripts, though not huge, is paid by every single user, and often over and over again
The cost of a change that effects N users is paid by N users.
user*N - change*N = user - change
> Against this cost for every user, one weighs the benefits of this change - which are zero.
That point specifically I am not arguing with. I agree this change doesn't seem to have merit. Remember: I am not the one imposing it on you.
Deprecating fgrep in a grep package distribution is just like deprecating a function in a library. The only reason it would be more difficult to handle that change is if you don't have a straightforward way of managing changes in your scripts and/or shell environments.
And that's the point I was making: it's very common for shell scripts to exist in unmanaged - and frankly brittle - environments. That's a problem that is not unique to this situation.
---
Here's an example:
If someone deprecated the printf() function in gcc version 127.4, replacing it with print(format=False,...), then anyone using gcc 127.4 would have to make a straightforward change to their code. Would it be annoying and pointless? Yes, that's the criteria for this hypothetical situation. Would it be difficult to manage? No, not really. You would just update your gcc dependency version, find and replace printf, sanity check, commit, done.
The reason deprecating fgrep is scary is that people tend to manage shell scripts more liberally. In other words, they likely aren't managed at all. Are they in a git repo? Who is running it? On what machine? What user? Critically, there probably isn't a clear way to predict what version of grep is going to be installed in what environment, and when.
This isn't a new problem. Package maintainers diverge all the time on what binary names and aliases they provide. Tell me, if you opened a shell on any random GNU/Linux system you have access to, and typed "python", would it be version 2 or version 3? Would python3 be in the path?
It's valuable to be able to manage these things. That's why projects like Nix are so popular.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#270Earlier quoted context omitted.
Different behavior based on argv[0] was first brought to my attention when I discovered that /bin/sh was a symlink on some Linux systems. Bash has a Bourne shell compatibility mode.
Bash actually has a POSIX compatibility mode. There is a great deal in POSIX that was not in Bourne, native arithmetic expressions being the first to come to mind, then new-style command substitution. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... All of the POSIX utility standards, including the grep variants, can be found in the URL's parent directory: https://pubs.opengroup.org/onlinepubs/96999197…
> Bash actually has a POSIX compatibility mode.
It's partial. A short example is `date&>FILE`.
[edited typo]
On a POSIX shell, `date` will run in the background and the date will be written to stdout (`date&`) and `FILE` will be created or truncated (`>FILE`). Using `bash --posix`, the date will be written to `FILE`, since the incompatible bashism `&>` still takes priority.