Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    GNU Grep 3.8 was released today for this commonly-used command-line utility for search plain text data. With the GNU Grep 3.8 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Sorry, but I will keep using egrep because it's easier and faster to type for me than grep -E.

    Comment


    • #3
      (..) such as a shell script named @command{egrep} with the following contents
      A shell script file named that way? What did he really mean?

      Comment


      • #4
        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.
        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.

        Comment


        • #5
          Originally posted by ssokolow View Post
          More reason for people to switch to Go or Rust for shell-script writing, I guess.
          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.
          Last edited by coder; 03 September 2022, 09:06 PM.

          Comment


          • #6
            Originally posted by tildearrow View Post
            Sorry, but I will keep using egrep because it's easier and faster to type for me than grep -E.
            Sounds like a fine use for an alias. Maybe shortem it to "eg" while you're at it.

            Comment


            • #7
              Originally posted by tildearrow View Post
              Sorry, but I will keep using egrep because it's easier and faster to type for me than grep -E.
              There is a question here will be at end.
              Code:
              alias egrep='grep -E'​
              alias fgrep='grep -F'​
              For user typing into computer that would put back the functionality. Both bash and dash support this.
              Originally posted by cl333r View Post
              A shell script file named that way? What did he really mean?
              "@command{egrep}" is processed to be only "egrep" in the document viewer. So the documentation is saying create a shell script named egrep or fgrep as need.

              Originally posted by ssokolow View Post
              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.
              Static linking brings another set of problems. Thing to remember all your common posix shell scripts support alias option. So removed egrep or fgrep you add line or 2 to the shell script as a lazy fix to redirect to grep command.

              The shell script work around would be need if python or some other language has people using fgrep or egrep. Otherwise just create alias will be the better option.

              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.

              From my point of view something has to happen with egrep and fgrep as individual binary they need to go away for a two reasons:
              1) they are not compact versions as they were meant to be instead have just come full grep an option set so no memory saving here.
              2) this is just waste of disc space due to be individually built binaries cannot be COW merged.

              So replaced with shell script files or aliases in fact makes sense. Yes replaced with shell script files redirecting to grep end users would not notice the difference in majority of cases. Yes the shell script to redirect to grep on disc will end up smaller than having egrep or fgrep. Memory usage make almost zero difference but not perfectly zero difference with the shell script route. Of course alias from egrep/fgrep to grep will in fact consume slightly less memory yes the forced set option ends up making egrep and fgrep slightly bigger on memory foot print.

              The question here is other than shell scripts and user interactions you can fix by adding alias options who else is using fgrep or egrep directly? << This is important question. Alias may be the correct answer here as in remove egrep and fgrep binaries and replace them with default shell script aliases better memory usage and better disc usage if this route suites your use cases.

              Comment


              • #8
                Originally posted by ssokolow View Post
                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.
                That makes absolutely no sense.

                Comment


                • #9
                  Originally posted by cl333r View Post
                  A shell script file named that way? What did he really mean?
                  Ikr, why not just set an alias in bashrc? Seems so much simpler

                  Comment


                  • #10
                    Originally posted by coder View Post
                    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.
                    Eloquently put. Perl is a cool language, I know just enough to be dangerous. It simplifies things from shell programing so easily.
                    Case in point my Shell Scripting for System Administration professor had us do a program to add a user with all the options in Debian based Linux we did it the first time in Bash, then we did it in Perl and it was so much easier. The program resides on my own Linux VPS at this address, https://kylewillett.net/addloginid.txt It is kind of cool!

                    Comment

                    Working...
                    X