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

  • #71
    Originally posted by mdedetrich View Post
    I would however gladly use either instead of shell, I also had to deal with getting woken up a decade ago when writing shell scripts.
    Better than getting woken up to fix a shell script you wrote a decade ago! Dohohohohohoh!

    Comment


    • #72
      oiaohm Aliases in /etc/profile won't work. /etc/profile is only read by login shells, which shell scripts aren't.

      Comment


      • #73
        Originally posted by oiaohm View Post
        ​No ssokolow you care how it's achieved. Person using lutris on Linux can have quite a simple time installing lots of the old Loki games due to the above project. Why the provide a legacy runtime. Steam store has a lot of really old Linux native games that work. Guess what steam runtime for compatibility.
        OK, fair. I care about first-party vs. third-party solutions. (And Lutris in particular, I don't like because I don't like the UI. I have plans to write my own alternative launcher UI.)

        Originally posted by oiaohm View Post
        Something to remember the Linux kernel in 64 bit mode still supports 16 bit protected mode for win16 applications. The 64 bit Linux kernel has more backward compatibility than 64 bit Windows kernel like it or not. Linux user space is able to be massive backwards compatible.
        Good point. The Linux kernel is best-in-class... it's just userland that's got a bad attitude.

        Comment


        • #74
          Originally posted by yump View Post
          oiaohm Aliases in /etc/profile won't work. /etc/profile is only read by login shells, which shell scripts aren't.
          The reality by posix standard there should not be any egrep or fgrep in shell scripts that people need. Remember posix standard egrep and fgrep by applications/shell scripts should not have been used for 20 years.

          The shell scripts that convert egrep and fgrep to grep command really should cease to be part of the grep package. For users typing in commands the alias will do. Remember when creating a new shell script today you should not be using egrep or fgrep so those failing to work in a shell script by default will slow down people from making more shell scripts using egrep and fgrep.

          Yes there is a lot of documentation out there that is simply wrong and has been wrong for a long time.

          The GNU grep lead developer is right its past time people to stop using egrep/fgrep by shell script or by application. There has been over 2 decades of notice that egrep and fgrep at some point would go away. Any party caught out by this could have other things in their scripts that are not correctly future proof/cross platform.

          Comment


          • #75
            Originally posted by oiaohm View Post
            There has been over 2 decades of notice that egrep and fgrep at some point would go away. Any party caught out by this could have other things in their scripts that are not correctly future proof/cross platform.
            Where? I've been using them since the early 2000s and the only mention I ran across was the "These variants are deprecated, but are provided for backward compatibility." in the man page... and I just assumed it'd be like the deprecated stuff in the Python 2.x standard library which was deprecated, but preserved in perpetuity to keep things from breaking.

            If they were planning to actually remove them back then, they completely failed at managing user expectations.

            Comment


            • #76
              Originally posted by ssokolow View Post
              Where? I've been using them since the early 2000s and the only mention I ran across was the "These variants are deprecated, but are provided for backward compatibility." in the man page... and I just assumed it'd be like the deprecated stuff in the Python 2.x standard library which was deprecated, but preserved in perpetuity to keep things from breaking.

              If they were planning to actually remove them back then, they completely failed at managing user expectations.
              Yes written as deprecated means you should not be using it in new scripts because they could disappear in future. Sorry deprecated parts of Python 2.x standard library not all of them have remained for perpetuity.
              https://peps.python.org/pep-0594/
              Next round of removals has started landing on the python standard library. This is just the most current cut of deprecated items but there have been 4 older PEP doing removals yes python 2.x and Python 1.x have deprecated then removed actions as well.

              You are right there has been expectations problem. Items marked as Deprecated or Withdrawn new code should not be using them.

              https://www.phoronix.com/news/Linux-...SYSCTL-SYSCALL
              Yes even the Linux kernel does remove stuff that has been deprecated for long enough and there are no longer any believed users.

              This is the problem the idea that deprecated stuff will be preserved for perpetuity is not reality. Never has been reality even on Windows or the Linux kernel.

              ssokolow the correct way to handle items that are marked as deprecated is stop using them because they will be removed in future. Items should not need to be preserved for perpetuity if people obey the deprecation or to be withdrawn notifications. Think about it how many of us are using scripts that are over 20 years old. If over the past 20 years everyone had obeyed the notification of deprecation/to be withdrawn the fact egrep and fgrep going away would only be a minor problem in very rare corner case.

              You write "I Just Assumed" yes you just just made "It makes an ASS out of U and ME" mistake.

              Deprecated need to be read as will be removed in future how many months/years/decades/centuries into the future we don't know but 99.999 percent of the time it will be removed. The 0.001 is the rare case that something gets marked as deprecated and developers change their mind and remove the deprecated status.

              I will give you user expectations around deprecated stuff has been very incorrect. Too many people class deprecated warning and notes as items they can straight up ignore.

              There is a reason why you need more than 1 runtime. Old programs do need a old runtimes with features that are removed from new runtimes. Reason for this split is so that people don't keep on using items marked as deprecated in new programs.

              Comment


              • #77
                Originally posted by oiaohm View Post
                ...
                First, that's Python 3.x. As far as I'm aware, Python 2.x followed proper "bump the major version when you break API" standards and didn't remove anything until 3.0.

                Second, that's 2019, while I was talking about the period from 2002 onward.

                Third, if the grep maintainers had plans to actually remove egrep and fgrep, they should have made the message in the manpage say something like the "Deprecated. Will be removed in Python 3.xx" banners in the Python docs.

                Fourth, that reinforces my sense that it was the right decision to migrate to Rust as quickly as feasible, given that "fearless upgrades" are one of their goals:
                • Barring fixing compiler bugs and unsoundness, which is explicitly exempt, they've promised that upgrading the compiler or standard library should never break a Rust build, and they've built a lot of infrastructure for checking for active users when considering making a breaking chance to fix something that turned out to really be a terrible idea.
                • As long as you have a Cargo.lock, it requires admin intervention to remove you access to a non-stdlib thing on Crates.io, and they only do that for things like copyright violations.
                • I can easily use the *-musl targets for pure Rust stuff to make builds that are completely statically linked and depend only on the Linux kernel, which has a much more favorable stance on API stability. (Thus ensuring that, in the worst case, I can​ keep using the old binary for however long it takes for it to be "a good time" to get the source building again.)
                Nonetheless, that's my own stuff, so I've been meaning to check what Flathub's policy is on unmaintained stuff. (i.e. In 10 or 20 years, can I still write something which spins up an emulator for a compatible ISA, install something from the Debian old version repo in it, and pull down a Flatpak package that was never rebuilt on something newer than one of the out-of-support runtimes?)

                Comment


                • #78
                  Originally posted by shmerl View Post
                  I just use ripgrep.
                  Ripgrep is the only grep. Functionality of ack, SilverSearcher, etc, but faster than even grep when using -E and -P (Especially the latter). Some of the Rust CLI utilities are the bee's knees. Not convinced they're faster, benchmark them with hyperfine. They are gradually replacing common utilities with even better ones:
                  grep --> rg
                  find --> fd
                  cd --> z (Zoxide)
                  ls --> exa
                  fzf --> sk (skim)
                  cut --> hck
                  The list goes on and on. Although awk and sed seem to be safe.

                  Comment


                  • #79

                    Originally posted by ssokolow View Post
                    First, that's Python 3.x. As far as I'm aware, Python 2.x followed proper "bump the major version when you break API" standards and didn't remove anything until 3.0.)
                    https://docs.python.org/3/whatsnew/2.1.html PEP 230: Warning Framework this is 2001. Python started removing items in 2001 with notification. Prior to 2001 stuff use to disappear without notification.

                    Originally posted by ssokolow View Post
                    ​Second, that's 2019, while I was talking about the period from 2002 onward.
                    Yes I was talking about from day one python. I just gave the most recent PEP.

                    Originally posted by ssokolow View Post
                    ​​Third, if the grep maintainers had plans to actually remove egrep and fgrep, they should have made the message in the manpage say something like the "Deprecated. Will be removed in Python 3.xx" banners in the Python docs.

                    Python does not always provide removal date or version. Yes deprecated one version removed the next does happen with python quite few times. What GNU grep is doing here is exactly to python level of deprecation support.

                    Too many cooks in kitchen is a serous problem with grep. Posix standard defines you grep interfaces then GNU, BSD, Busybox.... all implement grep. Yes you have just got notification from the GNU grep maintainers now. Posix standard has no requirement for items marked as withdrawn or to be withdrawn in the Posix standard to then have that information put in implementation documentation.

                    Please note its not just grep/fgrep/egrep its all command line items of posix that have been withdrawn or to be withdrawn from the standard that the makers of those have not been marking in their documentation that they are deprecated/withdrawn. This is basically tip of very big iceberg that really should not exist.

                    Originally posted by ssokolow View Post
                    Fourth, that reinforces my sense that it was the right decision to migrate to Rust as quickly as feasible, given that "fearless upgrades" are one of their goals:
                    • Barring fixing compiler bugs and unsoundness, which is explicitly exempt, they've promised that upgrading the compiler or standard library should never break a Rust build, and they've built a lot of infrastructure for checking for active users when considering making a breaking chance to fix something that turned out to really be a terrible idea.
                    • As long as you have a Cargo.lock, it requires admin intervention to remove you access to a non-stdlib thing on Crates.io, and they only do that for things like copyright violations.
                    • I can easily use the *-musl targets for pure Rust stuff to make builds that are completely statically linked and depend only on the Linux kernel, which has a much more favorable stance on API stability. (Thus ensuring that, in the worst case, I can​ keep using the old binary for however long it takes for it to be "a good time" to get the source building again.))
                    Problem here is you have not studied enough history of program languages. Lots of them start off with the goal of "fearless upgrades" yes that was a stated goal of python 1 but by 2.1 they had learnt something. I also think it funny that rust has the command cargo. Fearless upgrades very quickly leads to one of the forms of "Cargo cult programming" where you have stacks of code that no one is really using but you are maintaining anyhow. Even with all rust checking on active users.

                    The reality with the standard library is you don't 100 percent know the future and that the problem so like it or not stuff is going to be added to the standard library that make sense today that in 5 to 10 years will need to be removed. Deprecation system turns out to be very important. Means to split into generations also turns out to be important.

                    What you are doing with -musl to static link is wrong if you know history. https://sdl-mirror.readthedocs.io/en...ME-dynapi.html SDL 2.0 dynapi like feature is something you should want when you static link stuff in. I noted before the Linux kernel does at times remove very old syscalls this means you need the ability to replace the libraries that directly interface with kernel at some point in the future does change. Programs that use dynamic linking there are ways to update the libraries if required same with programs that have solution like SDL dynapi. Lot of ways old school static linking need to go away for core interfacing libraries and replaced with something like SDL dynapi. Yes the SDL 1.2 compatibility layer to SDL 2.0 is only really useful because SDL 1.2 applications 99% of the time are dynamic linked to avoid LGPL issues. Yes the SDL 1.2 compatiblity layer to SDL 2.0 is now need because lot of old SDL 1.2 applications that are closed source binaries no longer work due to system changes.

                    Yes another problem how to update old runtimes there is a lot of developer hours in doing that.

                    Originally posted by ssokolow View Post
                    Nonetheless, that's my own stuff, so I've been meaning to check what Flathub's policy is on unmaintained stuff. (i.e. In 10 or 20 years, can I still write something which spins up an emulator for a compatible ISA, install something from the Debian old version repo in it, and pull down a Flatpak package that was never rebuilt on something newer than one of the out-of-support runtimes?)
                    From the flatpak run command.
                    --runtime=RUNTIME
                    Use this runtime instead of the one that is specified in the application metadata. This is a full tuple, like for example org.freedesktop.Sdk/x86_64/1.2 , but partial tuples are allowed. Any empty or missing parts are filled in with the corresponding values specified by the app.
                    --runtime-version=VERSION
                    Use this version of the runtime instead of the one that is specified in the application metadata. This overrides any version specified with the --runtime option.
                    The reality of flatpak is that by default it will run the application with with whatever runtime is defined in the applications metadata include out of date runtimes. Yes flatpak application will warn you that you have installed out of date runtimes. Of course flatpak includes method to allow user to force run times.

                    Flathub themselves don't need keep unmaintained stuff around forever. Yes when hosting applications in your own flathub repository you should also host the matching run-times. Lets say you have the same runtime in two different repositories with flatpak user will be asked what one to install.

                    https://blogs.gnome.org/mclasen/2018...installations/ Note the flatpak --verbose create-usb here that all the parts for the application are bundled up.

                    Big difference between snap and flatpak is the means to self host in flatbak so you are not locked to what ever flathub policies in future happen to be. This is also the thing to remember flathub could promise 10-20 years of support and in few years time something goes wrong and they cease to be operating service then what. At least with flathub other parties can spin up replacements or have your own made install media/servers to reinstall from. Snap if the snapstore goes away what are you going todo.

                    Comment


                    • #80
                      Originally posted by oiaohm View Post
                      What you are doing with -musl to static link is wrong if you know history. https://sdl-mirror.readthedocs.io/en...ME-dynapi.html SDL 2.0 dynapi like feature is something you should want when you static link stuff in. I noted before the Linux kernel does at times remove very old syscalls this means you need the ability to replace the libraries that directly interface with kernel at some point in the future does change. Programs that use dynamic linking there are ways to update the libraries if required same with programs that have solution like SDL dynapi. Lot of ways old school static linking need to go away for core interfacing libraries and replaced with something like SDL dynapi. Yes the SDL 1.2 compatibility layer to SDL 2.0 is only really useful because SDL 1.2 applications 99% of the time are dynamic linked to avoid LGPL issues. Yes the SDL 1.2 compatiblity layer to SDL 2.0 is now need because lot of old SDL 1.2 applications that are closed source binaries no longer work due to system changes.
                      The difference is that I'm neither distributing these things as closed-source software nor linking against high-level APIs like audio or X11. I have the source handy and, if I distribute them, it's as source.

                      This is just me giving the middle finger to "ERROR: Go wait for that to recompile and then SSH it over again. You didn't think you'd ever be running a Debian stable machine, so you compiled that on your daily driver Kubuntu machine with a newer glibc."​

                      Originally posted by oiaohm View Post
                      From the flatpak run command.

                      The reality of flatpak is that by default it will run the application with with whatever runtime is defined in the applications metadata include out of date runtimes. Yes flatpak application will warn you that you have installed out of date runtimes. Of course flatpak includes method to allow user to force run times.

                      Flathub themselves don't need keep unmaintained stuff around forever. Yes when hosting applications in your own flathub repository you should also host the matching run-times. Lets say you have the same runtime in two different repositories with flatpak user will be asked what one to install.

                      https://blogs.gnome.org/mclasen/2018...installations/ Note the flatpak --verbose create-usb here that all the parts for the application are bundled up.

                      Big difference between snap and flatpak is the means to self host in flatbak so you are not locked to what ever flathub policies in future happen to be. This is also the thing to remember flathub could promise 10-20 years of support and in few years time something goes wrong and they cease to be operating service then what. At least with flathub other parties can spin up replacements or have your own made install media/servers to reinstall from. Snap if the snapstore goes away what are you going todo.
                      That assumes someone else has backed it up. I'm coming at this from the POV of someone who's having to dig through the Wayback Machine and uploads of Walnut Creek "stuff scraped off BBSes" shovelware CD-ROMs for freeware/public domain libraries and reference materials for my DOS programming hobby.

                      Comment

                      Working...
                      X