It's Past Time To Stop Using egrep & fgrep Commands, Per GNU grep 3.8

[shmerl]

I just use ripgrep.

[oleid]

I just use ripgrep.

Same here.

rg --glob '*.cpp' -i MySearchString path/to/my/monolith

A very fast way to search my monolith

[jabl]

Really why ship 3 binaries to perform grep actions? Yes GNU grep source currently makes 3 binaries grep, egrep and fgrep and these are not symlinks like busybox but in fact full binaries.

Really? At least here on Ubuntu 22.04:

$ cat /usr/bin/fgrep
#!/bin/sh
exec grep -F "$@"

(and same for egrep). Looking at the upstream git repository this is not a Ubuntu specific patch, it's straight from upstream.

[Artim]

I just use ripgrep.

Or just use ripgrep-all, which can handle even more file types. Though it hasn't been added to official repos yet.

[oiaohm]

Really? At least here on Ubuntu 22.04:

$ cat /usr/bin/fgrep
#!/bin/sh
exec grep -F "$@"

(and same for egrep). Looking at the upstream git repository this is not a Ubuntu specific patch, it's straight from upstream.

Turns out I was a little out of date. Been a while since I had built grep from source. 2014 upstream changed over to using shell scripts for egrep and fgrep.

Last time I built gnu grep from source it was still building 3 binaries and it had been that way over a decade..

[Lycanthropist]

What is the difference between "$@" and "$@@"? I've never come across the latter before.

[kpedersen]

More reason for people to switch to Go or Rust for shell-script writing, I guess. If the regexing is statically linked, you don't have to worry about them yanking it out from under you.

Or use a more "boring" OS like BSD. The advantage is that it almost never sees this kind of annoying changes. Though a disadvantage is it probably wouldn't ever have convenience wrappers like fgrep and egrep in the first place.

[evert_mouw]

I'm still with Bash for simple shellscripts, especially on servers (highly portable), but Julia might be attractive if you're looking for something else on your workstation.

The classic languages in this domain are Perl and Bash. Perl has the reputation of being "write only," and Bash is much worse than that! However, both are languages that emphasize pragmatism over purity, and that seems to be a win for short scripts. Julia is more readable than either of these, but it is not less pragmatic. ... For me, the appeal is that it feels good to write. It's like all the things I like from Python, Perl and Scheme all rolled into one. ... Semantically and syntactically, it feels similar to Python and Ruby, though it promotes some design patterns more common in functional languages and doesn't support classical OO patterns in the same way. Instead, it relies on structs, abstract types, and multiple dispatch for its type system. ... While keeping the syntax fairly clean and straightforward, the Julia ethos is ultimately about getting things done and empowering the programmer. ... This ethos fits very well with system automation.

Read Administrative Scripting with Julia by Aaron Christianson.

[ssokolow]

No, it's not. If something made sense to be a shell script, in the first place, this really doesn't change that calculus.

Shell scripts excel at:

• executing programs
• collecting & acting on their return codes
• stream management
• job management
• file manipulation

Yes, you can do those things in any language, but only with considerably more complexity and verbosity. If you appreciate using the right tool for the job, then something like egrep/fgrep deprecation would barely be a rounding error in the calculation of which to use for what.

About the only language I've seen that even comes close to shell scripts, for those things, is Perl. And that owes to the fact that it was explicitly designed to supersede shell scripts. I don't particularly like Perl, but I respect its strengths.

As an aside, I think one of Perl's biggest liabilities is also the reason it caught on so quickly: how much it borrowed from the tools that preceded it. That meant people coming from the background of writing csh scripts with lots of awk and sed could take to it like a fish to water, but those from any other background would have a big learning curve to climb. Python won out, due to its approachability, portability, and focus on core language features ...but it sucks, if what you really wanted was a shell script.

Actually, I stopped using shell script except in very specific "Python's runtime takes a second to start" use-cases years ago and I'm migrating to Rust now.

I much prefer having:

* Program execution and exit code handling that isn't a giant footgun
* Whitespace/quote handling optimized for code, rather than interactive use (Yes, I'm also one of those people who hates Haskell's currying-based braceless syntax)
* try/except, rather than trap
* Performance not hamstrung by having to fork/exec far too often and repeatedly incur the subprocess's startup overhead (Just today, I rewrote a shell script into Python because invoking flatpak info -m once per package was making it take 6 or 7 seconds. Now, it takes 1 second to start Python and then completes instantly by speaking directly to libflatpak.)
* Support for nested arrays (Another thing the rewrite benefited from. I can do {'from': ['to1', 'to2']} )
* File manipulation that doesn't require cutting together two or three subcommands with their own DSLs.

On this point, I believe the authors of The UNIX-HATERS Handbook were correct and shell script is trash for anything longer than three or four lines compared to the languages that were on the horizon when that book was released.

As for going from Python to Rust, "if it compiles, it usually Just Works™" is a real thing and I find spending the effort up-front more satisfying.

Heck, the main reason I didn't rewrite from shell to Rust for that script I did today was that I only realized I could probably access what I needed via GObject Introspection part-way through the process and Rust didn't have any non-GIR bindings for what I needed.

[ssokolow]

Or just use ripgrep-all, which can handle even more file types. Though it hasn't been added to official repos yet.

I actually wrote my own alternative to that because:

1. It's AGPLed and I want to share the relevant code with a web server where I don't feel like having to double-check that I'm complying with thw AGPL.
2. I want depth within the scope I care about and it seems to be focused on breadth of scope. (I want to grep inside documents of various formats and to try to implement "Reader Mode" conversions that I don't see anyone else having offered up, while they spent their effort on things I don't care about and would have to actively pref off to keep them from being a detriment, like grepping metadata out of audio/video files.)