GNU Grep 3.8 Starts Issuing Warnings About Using Egrep and Fgrep (phoronix.com) 86
After 104 commits from six different people, GNU grep was released Saturday, reports Phoronix.
The biggest change? "It's now made more clear that if you are still relying on the egrep and fgrep commands, it's past due for switching to just grep with the appropriate command-line arguments." The egrep and fgrep commands have been deprecated since 2007. Beginning with GNU Grep 3.8 today, calling these commands will now issue a warning to the user that instead they should use grep -E and grep -F, respectively.
Eventually, GNU Grep will drop the egrep / fgrep commands completely but there doesn't seem to be a firm deadline yet for when that removal will happen.
From grep's updated manual: 7th Edition Unix had commands egrep and fgrep that were the counterparts of the modern 'grep -E' and 'grep -F'. Although breaking up grep into three programs was perhaps useful on the small computers of the 1970s, egrep and fgrep were not standardized by POSIX and are no longer needed. In the current GNU implementation, egrep and fgrep issue a warning and then act like their modern counterparts; eventually, they are planned to be removed entirely.
If you prefer the old names, you can use use your own substitutes, such as a shell script...
Other notable changes from the release announcement:
The biggest change? "It's now made more clear that if you are still relying on the egrep and fgrep commands, it's past due for switching to just grep with the appropriate command-line arguments." The egrep and fgrep commands have been deprecated since 2007. Beginning with GNU Grep 3.8 today, calling these commands will now issue a warning to the user that instead they should use grep -E and grep -F, respectively.
Eventually, GNU Grep will drop the egrep / fgrep commands completely but there doesn't seem to be a firm deadline yet for when that removal will happen.
From grep's updated manual: 7th Edition Unix had commands egrep and fgrep that were the counterparts of the modern 'grep -E' and 'grep -F'. Although breaking up grep into three programs was perhaps useful on the small computers of the 1970s, egrep and fgrep were not standardized by POSIX and are no longer needed. In the current GNU implementation, egrep and fgrep issue a warning and then act like their modern counterparts; eventually, they are planned to be removed entirely.
If you prefer the old names, you can use use your own substitutes, such as a shell script...
Other notable changes from the release announcement:
- The confusing GREP_COLOR environment variable is now obsolescent. Instead of GREP_COLOR='xxx' use GREP_COLORS='mt=xxx'
- Regular expressions with stray backslashes now cause warnings
Huh? (Score:5, Insightful)
Can't they just make egrep and fgrep into aliases for grep with the appropriate command line parameter added?
ie. Not break things just because they don't like them.
Re: (Score:2, Insightful)
15 years isn’t enough time to fix your code?
Re:Huh? (Score:5, Insightful)
It's not my code.
Re:Huh? (Score:5, Insightful)
In many cases it's old scripts where the maintainer left many years ago but they work as they should.
Don't fix it if it's not broken.
Changes like this is what really causes bugs, not fixes them.
Many years ago I tried grep -E instead of egrep and experienced different result. Something was different, but I don't remember now since it was probably 15 to 20 years ago.
Another factor is that if you remove egrep/fgrep you'll end up in environment specific scripts that have to know if it's a GNU environment or another *NIX environment. At best you can get around it with conditional statements, but it will then require editing scripts with potential for new bugs.
Re:Huh? (Score:4, Interesting)
Many years ago I tried grep -E instead of egrep and experienced different result. Something was different, but I don't remember now since it was probably 15 to 20 years ago.
That's probably because, unless one is aliased to the other, you'd be running version 1.52 of egrep and version 17.3 of grep. It's a nasty catch-22, people used egrep because they wanted to do exotic things that grep wouldn't do and then ended up hardcoding in egrep-specific quirks that aren't replicated in grep -E.
Re: (Score:2)
...ended up hardcoding in egrep-specific quirks that aren't replicated in grep -E.
Well there's your problem.
How hard can it be to add the quirks?
Re: (Score:2)
Dunno... got a list of those quirks and how they are being used?
Re: (Score:2)
That isn't a realistic answer.
Why are you upgrading grep on a system that isn't being maintained any longer?
We're not 'upgrading' anything. We're copying old, working, scripts onto a newer machine.
Re: (Score:2)
same difference - the expectation that a working script working on one machine should work on another, different machine is ... uh, your problem, not GNUs. it could break for a million different reasons, including legitimate important fixes or changes you're seemingly against like the one in the article because you think your script should be magical
Re: (Score:2)
Except in this case there's really no good technical reason to break them.
Re: (Score:2)
The thing I'm not entirely clear on is whether there's actually a functional difference between invoking it as egrep vs. "grep -E" (or the fgrep equivalent). If egrep/fgrep is using some different codepath emulating quirks of the original programs, it means there's different codepaths that need to be updated, tested as part of regression testing, and validated for any releases or code pushes. I could see the point in working on dropping that since it's probably complicating testing and may be non-standard a
Re: (Score:2)
In many cases it's old scripts where the maintainer left many years ago but they work as they should. Don't fix it if it's not broken.
It is precisely the idea that you should always replicate and ensure all past behaviours work that either prevents progress going forward or worse causes bloat. Sure we're only talking about grep here, but apply your logic to a bigger project and you'll very quickly get to the mess that is a modern bloated OS.
If you so desperately depend on a prior version, don't upgrade. It's as simple as that. You should not expect future systems to cater to your edge case of the past with 100% backwards compatibility. Th
Re: (Score:2)
It's more than backwards compatibility.
Not every *NIX dialect has the same implementation of grep/egrep/fgrep. I.e. they are using their own instead of the GNU version. That's just a fact, so if you on one dialect need to use "egrep" and another "grep -E" then you are causing problems. The other dialect may not be "old" per se, just a different part of the heritage tree, but you still want your software to work as good as possible on as many dialects as possible. So unless you can convince the maintainers o
Re: (Score:2)
Based on the summary where it says egrep/fgrep didn't make it into POSIX I assume that means that grep did...
But does POSIX just say "have something that finds strings in other strings/textfiles" or does it get down to the arguments and what expected behavior should be (ie, use-case testable stuff) ?
Re: (Score:1)
This is the POSIX synopsis for grep:
grep [-E|-F] [-c|-l|-q] [-insvx] -e pattern_list
[-e pattern_list]... [-f pattern_file]... [file...]
grep [-E|-F] [-c|-l|-q] [-insvx] [-e pattern_list]...
-f pattern_file [-f pattern_file]... [file...]
grep [-E|-F] [-c|-l|-q] [-insvx] pattern_list [file...]
It describes what all of that means in detail.
The GNU man page is incorrect when it says egrep and fgrep were not standardi
Re: (Score:1)
I reported the man page problem and the GNU grep maintainer has installed a patch: https://debbugs.gnu.org/cgi/bu... [gnu.org]
Re: (Score:2)
Thanks. Wish I could upvote ya...
Re:Huh? (Score:4, Informative)
Just use ripgrep and be done with it.
https://github.com/BurntSushi/... [github.com]
Unlike grep, it's optimized for computers that were made within the last 20 years, so it runs a hell of a lot faster. Easily the fastest 'grep' like tool that exists. Sure, it's not POSIX compliant, but neither is Linux, and for very good reason in both cases.
There's also fd-find for general file name searches, which works with similar assumptions, and is similarly fast:
https://github.com/sharkdp/fd [github.com]
Re:Huh? (Score:4, Insightful)
Backwards compatibility is important.
There is no gain from removing these commands.
By removing them anyway, the maintainers demonstrate that they don't understand the importance of backwards compatibility. Which is a problem.
Re: (Score:2)
something like,
/
grep -class -indent 3 {
grep -indent 5 print "hello"
grep -indent 3 }
?
Zawinski (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Can't they just type 1 less letter for compatibility reasons after 15 years? I know that is a lot to ask, (less work and compliance) but even the densest of rocks can change.
Re: (Score:2)
I know the feeling. I don't see why POSIX compatibility is a reason not to keep egrep and fgrep; afaik, POSIX doesn't forbid you from using those names, it just means that you also have to have the -E and -F flags on your regular grep.
I guess I'll define an alias, 3 fewer characters to type (and one of them a stretch for my clumsy fingers). And yes, this dense rock *could* change, but why? Isn't the idea of Linux that you can make things work the way you want to? Or is the POSIX straitjacket taking that
Re:Huh? (Score:4, Funny)
Hmm... spend an in significant amount of time preparing a legacy hack using an alias, or ask thousands of people to waste countless millions of man-hours of effort rewriting stable code for no good reason?
Tough choice!
Re:Huh? (Score:5, Funny)
Python says hold my beer!
Re: Huh? (Score:1)
In ascii art, braces can be hands. Python ain't holdin nobody's beer.
Re: (Score:2)
In the Perl land, we chased off compat breakers to Raku. It also allowed them to go radical. So you can use a clean new design while your 20 years old scripts continue to work.
Re:Huh? (Score:5, Funny)
If only there was some command that you could use to find scripts that made use of egrep and fgrep...
Re: (Score:3)
Problem is that on some systems they are already aliases to grep, but on others they are binaries. Binaries that have been unsupported and unmaintained for years.
Particularly with scripts that are distributed, e.g. as part of a larger software package, there is a risk that they run on systems with old binaries that have security issues. Scripts for things like installing software or editing settings often run at higher than normal privilege levels too.
Re: (Score:2)
GNOME, which is GNU, went systemd (which is not GNU) rather than make good decisions.
At this point we can count on GNU to make bad decisions, like in this case not volunteering to deliver wrapper scripts to provide these functions in the grep distribution.
egrep and fgrep date from Version 7 Unix, from 1979. This decision literally breaks scripts older than the GNU project.
It's a valid question whether any of those are still being used today, but this still doesn't make any sense at all.
Re: (Score:2)
Re: (Score:3)
I'm rather amazed to hear that I had no idea egrep/fgrep were deprecated. I'm not exactly sure how I'd ever find out though - unless using them emits a warning (which would really break compatibility). Maybe slashdot posted a story about it 15 years ago and I missed it, or maybe it didn't - but it's taken me this long to know about it.
I'm now wondering what egreps I've used in the last 15 years - quite a few, I'm sure. I always though they were equivalent and symlinked/linked together, with grep just emulat
Re: (Score:3)
Can't they just make egrep and fgrep into aliases for grep with the appropriate command line parameter added?
AFAIK they effectively already are. If you look at the commit that added the deprecation warning [gnu.org] you'll see that it was added to "egrep.sh".
Wait, where's "fgrep.sh"? Well, it's also "egrep.sh", as "egrep.sh" uses compile-time substitution to serve as both on install, and all it does is launch "grep" with either -F or -E as appropriate. (In fact, you can see the part of the Makefile.am for building the final egrep and fgrep stubs immediately before the egrep.sh changes as they have a minor change as well.)
So
Re:Huh? (Score:4, Insightful)
I suppose it's "more optimal" to just call "grep" directly because it avoids running a second shell to build the new "grep" command
Also silly to turn it into a shell script. IMO software distributions should freeze on what version Grep will ship to one before the dumb warning was added and just start declining any further updates from the maintainers of grep (Keep the old version.. Are these new maintainers anyways who are bored and just trying to stir something up, or what?). Grep is already feature complete - any changes at this point other than bugfixes or performance tweaks are basically just doing everyone a disservice. I don't think there is Anything the maintainers could possibly add to the software at this point that would have a benefit worth the cumulative pain of the change.
Grep could easily check its command line opts and automatically set a flag if argv[0] ends with fgrep or egrep. This is what BSD Grep does and what I thought Linux was doing for a long time.. on MacOS fgrep, egrep, and grep are Identical binaries. On other systems fgrep and egrep are just symlinks to grep.
Re: (Score:2)
I just wrote a bad comment insisting they should include wrapper scripts :D
There is literally no reason to be bad at a wrapper script. None. It will do exactly the same job.
As usual, which I should have expected, this is a fart in a fart factory.
Re:Huh? (Score:5, Insightful)
Remember the old days when programs would check $0, and depending on the name used, behave differently?
Now we have to write a shell script, AND so that the braindamaged linux admin wannabes know it's a shell script, it has to end in ".sh", when an alias, or a bit of code that causes grep to run itself as "-E" when invoked as "egrep", would work just as well.
It's like modern Unix programmers don't actually grok Unix.
Re: (Score:2)
The Unix principle was to keep it simple. GNU/Linux followed those ideals. Systemd is not simple. It goes against the very principles of Unix.
Magic was just that. Who needs extensions?
As a side note: As someone pointed out. Ubuntu already has shell scripts to replace egrep/fgrep. They've been gone a while.
Those who don't grok Unix, almost certainly won't grok, grok?
Re: (Score:3)
The Unix principle was to keep it simple.
The first use of that principle was in 2003 in Raymond's book. I think you'll find Unix predates that principle, and Unix is filled chock full of systems that are far from simple. Case in point: SysV init which failed to do its one task and relied on complex scripts and even third party tools to do the bare minimum of managing system daemons, or X11 a system so complex that it was abandoned by many of its developers as unmaintainable.
If you want get more specific an older and different set of Unix principle
Re: (Score:2)
It's good software development practice in general, often expressed within the dev world as the Single Responsibility Principle ("SRP").
Much of software maintenance consists of refactoring fusty code that has been Band-aided, updated, and added to gradually over long periods of time, so that it comes closer to obeying the SRP.
What does happen sometimes is that people remove what they think is unnecessary complexity in one place, only to have it reappear in others, sometimes in a worse form. Thus, over time
Re: (Score:2)
On Gentoo, they are already scripts:
# file `which egrep` /bin/egrep: POSIX shell script, ASCII text executable
Re: (Score:3)
into aliases for grep with the appropriate command line parameter added?
You don't even need to add command-line parameters; commands can examine argument zero to find out the command that was used to run them and adjust their behaviour accordingly. Then you just make grep, egrep, and fgrep hard links to the same binary.
But my Ubuntu 20.04.3 LTS already has egrep as a shell script with just 'exec grep -E "$@"' as you suggest.
In UNIX land, this is dead easy. (Score:3)
You just make grep, egrep and fgrep hard links to the same file. The argument processing logic first checks argument $0, the file name that was called, and add -F or -E to the arguments as needed.
This is what stock bsd grep does - note the identical inode numbers -
$ls -i /usr/bin/grep /usr/bin/grep /usr/bin/egrep /usr/bin/egrep /usr/bin/fgrep /usr/bin/fgrep
15918623
$ls -i
15918623
1$ls -i
15918623
Re: (Score:2)
On OpenBSD that is what is already being done.
I do not know why GNU cannot use hard links like you say. It is not like it is rocket science.
Re: (Score:2)
Re: (Score:2)
You are forgetting scripts, yes you can use aliases for interactive use, but many scripts may need to be changed.
Yes you can alias that in the user I and modify your ID to ensure cron gets that alias, but issues can happen if you try [ef]grep with some quoting, and should you use execv(3) with [ef]grep, aliases will not work.
What about agrep (Score:5, Interesting)
"agrep" is the only grep software that I have been using since 1993. It has quite a few unique features not yet available in grep/fgrep/egrep. Ability to provide delimiter, search in binary files, approximate grep and so on. In 1993, it was also about 10 times faster than standard grep.
I became die hard fan when I was doing a research and we had to upload the paper for publication in 4 hours and realized that due to a software bug the data in our tables were wrong. The data were extracted using a software from over 1000 binary files, each about 5 MB. Introspecting the files, I found that most files had the required data in the first few blocks but there was no guarantee. I modified agrep to take "-l" option and also print a record and use a delimiter to extract the required data. The whole process less 2 hours (actual execution time only 30 min). I still can't think of anything else can do the required job even today.
I ported this to Windows in 1995. Since it is written with direct unix syscalls, compiling was a challenge. Then I noticed that MS Visual C++ 2.0 was converting c calls to unix signature syscalls before converting to Win32 api calls. I included compiler's internal header files and viola, it worked (with lots of warnings from compiler for using internal headers). The only modification I did was to add Windows way of handling command line args. Unfortunately, I lost the source code when the hard disk crashed. Since I had copied the binary to multiple machines, it survived. Believer it or not, I am still using that on my Windows machines but I can't distribute it.
Re: (Score:2)
I am mostly Mac user now last few years but still have one Window machine at home. The agrep compiles fine on all Macs including M1 Macs.
Re: (Score:2)
Yes, I know about the Windows port but I haven't used it for two reasons. Mostly moved to Mac and the one that I have has customization to print the record with line number if you use "-l" and "-n" together (So you get the speed of "-l" but you get to see the first matching record. See my first post, I used this feature there). The one I have is also 32 bit since I compiled it in 1995 when 32 bit itself was new to Windows (Windows NT 3.51 with MS Visual Studio 2.0 C/C++).
64 bit extension will be very useful
Re: What about agrep (Score:2)
Re: (Score:2)
Re: (Score:2)
I included compiler's internal header files and viola, it worked (with lots of warnings from compiler for using internal headers)..
Did you use a big violin to compile C code? This is news for nerds.
ag aka Silver Search (Score:3)
try Silver Search. It is so much faster than grep.
https://github.com/ggreer/the_... [github.com]
Why? (Score:3)
What good does this change do? It removes at most a couple of dozen lines of code that haven't changed in probably over a decade. It's not like this reduces the support burden of grep much. It seems to me like a gratuitous change that will just annoy users.
Jod pronounces it jrep (Score:5, Funny)
systemd could have prevented all this! (Score:5, Funny)
Why are people still using egrep and fgrep you can all do that with systemd while it brings World Peace at the same time?
Re: (Score:1)
If people could shoot each other over an internet forum not only would systemd not bring about World Peace, Slashdot itself would be a R-rated bloodbath!
Well MA rated. Not a lot of boobs here.
rg (Score:2)
Some people will switch to ripgrep.
Re: (Score:2)
Feels like Rust is slowly taking over the cli world. Rust haters deny it, but they also tend to think POSIX compliance is the only way to go, null should terminate all strings, etc.
My life will be so much richer now. (Score:2)
Not just removing a couple of aliases/hard links, but also giving me the opportunity to check my code for use of GREP_COLOR. And just when I was at a loose end!
Eventually, GNU will drop egrep/fgrep completely (Score:2)
This is your two-decade warning, You have twenty years left before egrep/fgrep support is utterly and finally removed forever. Don't dawdle, folks, this is not a drill!
Re: (Score:2)
Oh no! raise the alarm! This means war! Waaa-ah-ah! lolol
ROFLCOPTER
Some of these whiners should learn how to computer, they could fork it or make an alias or something.
Clarity (Score:2)
greppable file formats (Score:2)
I am not sure all of this egrep and fgrep business is important in the wider scheme of things. I am bloody sure that the world is a better place if you can crunch your data files with simple tools such as grep, rather than depending on vendor-specific tools. At the risk of going off-topic, one of the reasons I hate systemd is that it is not greppable. Frankly, I do not have a clue what is going on, because my usual investigative tools just don't work any more. Boot scripts using Bash could be pretty obscure
The old saying, (Score:1)
Good story! News for Nerds. Stuff that Matters (Score:1)
More of this ! and less about Apple's new baubles or Code.org's latest attempt to keep boys from programming or some dumb new unreplicated psychological research that shows nothing.
Re: (Score:2)