10 ms·

We are stuck with egrep and fgrep (unless you like beating people)

• im3w1l 4y ago
  Yet another reason why shellscripts are bad huh.
  • grnmamba 4y ago
    How does the article lead to this conclusion?
    • im3w1l 4y ago
      People are upset that changing literally anything on the system like adding a deprecation warning to stderr will break their fragile shellscript setup.
• indigodaddy 4y ago
  If they change this, when might we see it bubble into RHEL? 10?
• c7b 4y ago
  > typing 'grep -F' is two more characters, one of them shifted Adding in more special characters is also hostile to users who aren't based in a single English-speaking country and regularly have to deal with different keyboard layouts.
• midislack 4y ago
• kevincox 4y ago
  What problem is this warning trying to solve? Are these two symlinks too much maintenance burden? Or is the check in the code hurting the code quality? Is the extra check at startup ruining performance? I'm usually in favour of having one way to do things but in this case, with this much legacy it just doesn't seem worth it.
  • roenxi 4y ago
    This is free software. It is legitimate to consider convenience for the maintainers. If they don't want to maintain two symlinks then they are empowered to make that call. If anyone thinks it is a big enough problem that they want to fork the software they can, or the distros can maintain their own symlinks. But I think in this case the simple answer is if the maintainer doesn't want it in the source tarball then it isn't going to be there and that is more than sufficient a justification. Complaining is probably more reasonable than asking for a justification here.
    • raverbashing 4y ago
      > It is legitimate to consider convenience for the maintainers. Yes, but the convenience of... creating 2 symlinks and adding the flag based on argv[0]? Sorry, I don't buy it. Wanting to die on such a tiny hill has GNU written all over it though
    • Ensorceled 4y ago
      I don't know when society in general just said "Fuck It" to the idea of stewardship; but we now have it ingrained that people in positions of trust and power (whether volunteered, elected or appointed) are not morally or ethically beholden or responsible to the communities they have taken it upon themselves to represent. At least we used to pay lip service to that ideal.
      • Beltalowda 4y ago
        They didn't necessarily "choose communities to represent". As the maintainer and author of various open source libraries and tools that are used by many thousands, in most cases it's just that ... I'm one of the few willing to spend the time on it, and it's usually useful for myself as well. I don't really "represent" any community or anyone. That said, I certainly wouldn't have put in this change myself, because I wouldn't like to inconvenience anyone. But that's just basic good manners that you should have in every-day life to random strangers.
        • 4y ago
• Forge36 4y ago
  Why aren't these split into separate packages? If a distro wants to drop them, they can still be installed. If some distro wants to include them with a warning that's also fair game.
  • forgotpwd16 4y ago
    >Why aren't these split into separate packages? Because they're the same thing. What all is about are the `xgrep` commands being symlinks to `grep`. Though I guess you can have packages that just add the symlink. >If some distro wants to include them with a warning that's also fair game. Some distros already do what is recommended in release notes. Rather being symlinks they're wrapper scripts. E.g. in Nix the `fgrep` and `egrep` are just `exec ${nixpkgs.gnugrep}/bin/grep -F "$@"` and `-E` respectively.
    • ksherlock 4y ago
      GNU egrep and fgrep are wrapper scripts (and have been for 10 years for more). Wrapper scripts that now warn you not to use them. https://git.savannah.gnu.org/cgit/grep.git/tree/src/egrep.sh https://git.savannah.gnu.org/cgit/grep.git/tree/src/egrep.sh
      • henearkr 4y ago
        This should be the top comment lol. Such an insanity... They are wrapper scripts that precisely enable to obey to the advice the warning is giving, yet the warning ends up advising not using the wrapper...
        • henearkr 4y ago
          I cannot edit anymore, so I add this: This is the case in a distribution (Arch) that has effectively taken the maintainer's advice into account, not the reverse. So I was wrong, and let's not be unfair to the maintainer.
      • forgotpwd16 4y ago
• thepawn1 4y ago
  alias fgrep='grep -F'
  • VWWHFSfQ 4y ago
    the issue is that programs rely on the existence of fgrep in its PATH. your shell alias doesn't fix that.
    • jonas-w 4y ago
      It is a bit hacky but you could put "grep -F" in a script file in your path.
      • forgotpwd16 4y ago
        That's what GNU grep recommends: https://www.gnu.org/software/grep/manual/html_node/Usage.html#:~:text=what%20happened%20to%20egrep%20and%20fgrep%3F%20 https://www.gnu.org/software/grep/manual/html_node/Usage.htm...
    • emptyparadise 4y ago
      #!/bin/sh exec grep -E "$@"
      • Beltalowda 4y ago
        Of course it can be solved; no one claimed you can't. The choice here is: - Thousands of users have to update their scripts, habits, shell configs; or - The GNU Grep maintainers spend essentially zero minutes "maintaining" a few lines of code to automatically use -E or -F based on argv[0]. It seems to me the second is obviously the better option.
        • koprulusector 4y ago
          # unalias grep && unalias egrep && cp "$(command -v grep)" "$(dirname "$(command -v grep)")/egrep" 1 line. Fixed. Done. Btw needs to be run as root ( as signified by # prompt above) EDIT: see other comment in this thread from FreeBSD user that on FreeBSD grep, egrep, and fgrep are all separate but identical (copies) of the same file. So this isn’t quite such a silly solution as some might think.
• xpressvideoz 4y ago
  > The egrep and fgrep commands have been deprecated since 2007. Isn't 15 years more than enough time to handle the deprecation?
  • Beltalowda 4y ago
    I betcha most people didn't even know they were considered "deprecated".
    • ozim 4y ago
      There is so much outdated info on the internet in various forms that it is hard even to realize what is "proper modern way" of doing things unless you really are into Linux \ config stuff. I am casual user so I can get around system but modern ways always surprise me when I finally find out about it.
      • Beltalowda 4y ago
        And for all you know "grep -E" isn't supported on some system people use. This is not really a concern if you're just writing script for yourself (which are really >90% of scripts; portability often isn't really a concern), but knowing it will work on all systems – new and old – is pretty hard, and sometimes it does matter. Does it work on NetBSD? HP-UX? Solaris? Last year autoconf changed the `..` command substitution syntax to the "new" $(..) syntax and someone complained it broke on their ancient Solaris system. So ... people will stick with what works, like "egrep".
    • kibwen 4y ago
      And now they do, so perhaps it's working as intended. :P
    • gw99 4y ago
      Yes. This is the first I've heard of it and I've got a ton of scripts that are probably going to break.
    • LinuxBender 4y ago
• netfl0 4y ago
  Please put it back.
• ufo 4y ago
  The blog makes two main points: 1) adding new error messages causes compatibility problems; 2) some people are used to typing "egrep". On the first point the author only gives hypothetical examples. I feel the argument might have been more compelling if we could see some concrete examples of things that break with GNU Grep 3.8. As for the second point, I find it less convincing than the first one. If it's just the muscle memory then an alias would be an acceptable workaround. And I doubt that "everyone in the world" would want such an alias, as the author suggests.
  • airza 4y ago
    It seems pretty simple, piping bash commands into other bash commands and other text stream juggling is a pretty typical use of these commands and so changing what stream is output can change the behavior of consumers of the output of these functions. I haven’t done anything with fgrep and egrep before but piping grep into another grep for more complex classes of text search is something i use a lot.
    • tuetuopay 4y ago
      It's more than likely the warning will be printed to stderr, not out, so there will be no impact on the actual work done.
      • mannykannot 4y ago
        Automatically monitoring the stderr from cron jobs for unusual outputs is a prudent measure, and its plausible that this change will increase the burden of false positives (it certainly will not reduce it.)
        • loloquwowndueo 4y ago
          But if you’re monitoring the output it usually means you are in a position to fix problems which means you can likely update the script in question to use the new warning-less invocation.
• javier_e06 4y ago
  scripts will be break. Strange outputs will appear. Devops will rip the gowns and douse ashes on their heads. Patches will arrive and a years later someone will make a joke about fgrep like the jokes about ed, the GNU ed line editor.
  • rgoulter 4y ago
    Hopefully Devops will be able to make use of nice tooling like linters (e.g. shellcheck for bash) which can hope to catch such problems.
• TacticalCoder 4y ago
  Does the warning go to stdout or somewhere else?
  • Beltalowda 4y ago
    stderr
    • ur-whale 4y ago
      > stderr For now.
      • Beltalowda 4y ago
        Clearly that will never be done. Outputting this to stdout would be ridiculous and break everyone and everything using it. Might as well just outright remove egrep and fgrep. Ridiculous comment.
• liveoneggs 4y ago
  I use egrep and fgrep regularly. I guess I am just getting too old for GNU.
• throwaway67743 4y ago
  Funny, I've never ever used egrep or fgrep in the 20 odd years I've been operating systems, always preferred explicit flags to aliases or argv[0] evil.
• chriswarbo 4y ago
  I get the annoyance, for both the GNU maintainers and distro maintainers/sysadmins. I'm not too wedded to either outcome, but my take is that we should avoid global mutable state: - If you're relying on random globals (like the path /usr/bin/egrep) to (a) exist and (b) behave in a certain way, then don't mutate them. Stick with known-good versions, and treat updates like any other code change (review, test, etc.). This is the usual case for legacy systems. In other words, don't blindly run `apt-get -y upgrade` on systems which are meant to be stable. - Alternatively, don't use globals: install grep in its own directory (e.g. via the `--prefix` argument of `./configure; or using a sledgehammer like chroot), and treat that location as a capability (as per capability-security). Programs/scripts which need that grep must be given its location explicitly (either for direct calls, or by having it prepended to their $PATH). If you want to use an updated version elsewhere, just install that to a different location; no need to touch the existing setup. (Shout-out to Nix for doing this via ./configure and $PATH. Runner-up prizes for chroots/jails/zones/containers/VMs/etc.)
  • AshamedCaptain 4y ago
    Both of your suggestions are basically equivalent to "think before you upgrade" and/or "don't upgrade". This is the second elephant in the room with all these distros that "don't use globals" and/or statically link everything (or do an analogue to that, like nix). There's very little benefit for desktops. So the upgrade to dependency X breaks component Y, and you are forced not to update X, or at least, Y's copy of X. Great. What do you do now? Swim away from upstream? Stay on outdated components? The situation is as unatenable long-term as it is on a regular distro... The first elephant in the room is that generally you _do_ want most dependencies to be global state. Is a situation where every program is using its own version of the graphics toolkit, with different theming issues or even different themes altogether, really ideal for a desktop situation? What about libevent -- so that your mouse's wheel has one acceleration curve in some programs and some other speed in some other programs ? Or what about ibus, where generally having different client versions running simultaneously means your entire input system stops working ? Even grep is likely something that you'd prefer to be global state, lest the grep exec() by a Python interpreter have different features than the one launched by your main shell.
• usefulcat 4y ago
  This reminds me of the last time daylight savings time was changed (in the US). A bunch of hassle and software breakage.. for what? Just to get back to the same place we already were (working software)? What a waste.
• ziml77 4y ago
  I think it's a bit silly to get rid of such established aliases. Surely they aren't a real maintenance burden. Though I can't say I entirely hate it, for the (admittedly absurd) reason that egrep = grep -E, fgrep = grep -F, but pgrep != grep -P! It's an awkward incongruity that's easy to get tripped up on occasionally.
• deleted 4y ago
  [deleted]
• blacklight 4y ago
  While I hated the decision of adding warnings without much notice (which, in the case of such widely used CLI tools, is the equivalent of a breaking change), I also found an easy solution that would prevent my scripts from spitting out lots of unneeded warnings. alias egrep='grep -E' alias fgrep='grep -F' Now GNU developers can keep doing whatever they're doing, and I can keep doing whatever I used to do.
  • misnome 4y ago
    Your scripts expand aliases?
    • koprulusector 4y ago
      shopt -s expand_aliases
      • nyuszika7h 4y ago
        You still have to define the aliases or source your aliases file in every script though.
  • acdha 4y ago
    > While I hated the decision of adding warnings without much notice (which, in the case of such widely used CLI tools, is the equivalent of a breaking change) 15 years isn't “much notice”? I had already stopped using those back then because, as noted in the article, they weren't standardized and so you had to work about portability across Unix installations. It's also worth noting that this is only a breaking change if you are using the non-standard names in a context where you are trapping output. For the vast majority of people using a shell script which doesn't use the common name, they will at some point upgrade, see the warning, spend 30 seconds making the change, and never think about it again. If you're that sensitive to the extra work, presumably you also do some testing before installing new upstream releases. EDIT: it was actually 17 years ago that the warning was added about egrep/fgrep: https://git.savannah.gnu.org/cgit/grep.git/commit/?id=0b4859eebda2820bd469c1d2d424f1be3314050f https://git.savannah.gnu.org/cgit/grep.git/commit/?id=0b4859...
• ourmandave 4y ago
  Tangentially, I'm still searching for a grep for Windows you can run from file explorer. I've resorted to right-clicking a command window and using findstr. =( I'm sure there's also a powershell equiv but I haven't taken the time to walk the PS object tree to find it.
  • richard_todd 4y ago
    powershell has `sls` which expands to `Select-String`
• koprulusector 4y ago
  I’ve been using grep -E for a long time, I thought I remember it being from a warning from egrep or something.. can’t really remember for sure, though. Either way, I don’t see what the big deal is, just add an alias egrep='grep -E' If you’re worried about your non-interactive shell scripts, shopt -s expand_aliases; alias egrep='grep -E' and you can move on with your life. EDIT: I must’ve been warned by shellcheck EDIT2: here’s another one liner with one caveat being updates (also needs to be run as root) # unalias grep && unalias egrep && cp "$(command -v grep)" "$(dirname "$(command -v grep)")/egrep" EDIT3: just realized for most this will only ever come up in scripts because many distros already add alias egrep='grep -E' to your shell aliases (~/.bash_aliases, ~/.zshrc, etc). Thus you may only need the shopt -s expand_aliases.
  • 3pt14159 4y ago
    The problem is that we don't just live on our own machines. We hop around to different boxes and just being able to type what you are used to matters. My dotfiles and other tools don't go or even work everywhere. We shouldn't change the oldest parts of our OSes without a really good reason.
    • acdha 4y ago
      I find this reasoning interesting since it's why I _stopped_ using egrep/fgrep around the turn of the century: because those aren't standard, it wasn't uncommon to find that you depended on some behaviour which wasn't available in the version installed on some random server but it worked when you used grep.
      • markstos 4y ago
        I don't remember why I stopped using the shorter `egrep` and only use `grep -E`, but I suspect this was the reason. I used to work on a variety of BSD and Linux servers. I'm fine with this clean-up and simplification. Eventually, there will be more future users of `grep` than past users.
        • 4y ago
• mugwort13 4y ago
  [dead]
• lizardactivist 4y ago
  Happy to have left the mess that is grep, awk, bash, zsh, fish, etc. behind and just use Python for scripting.
  • 42e6e8c8-f7b8-4 4y ago
    I like hand saws and I like circular saws/Skil-saws. I use them for different things.
  • salawat 4y ago
    Python has it's own problems. Not the least of which being it being hundreds of times slower than coreutils. I'll take learning Shell and a handful of coreutils, over praying the sysadmin has successfully navigated/allowed me to navigate all the Python footguns. Also, good luck doing anything embedded where space is at a premium. Not all base systems have/need Python. Everything needs a shell, however.
  • dahart 4y ago
    Hehe, wasn’t the Python 2 to 3 incompatibility debacle a thousand times worse than [fe]grep? Python2 is still lingering in places even after Python 2 was removed.
• dncornholio 4y ago
  Unnecessary potentially breaking change. I'll rest my case.
• cestith 4y ago
  " there's a difference between avoiding fossilization and the kind of minimal, mathematical purity that we see GNU Grep trying to impose here. Unix has long since passed the point where it had that sort of minimalism in the standard commands. Modern Unix has all sorts of duplications and flourishes that aren't strictly necessary, and for good reasons." Well, really, the type of purity many of the original Unix hands desired was that each tool did one thing well, not that one tool did everything well. Some folks would say that putting the -E and -F flags in GNU grep in the first place instead of using egrep and fgrep was the wrong direction. Now GNU is wanting to further consolidate the hydra.
• jagtesh 4y ago
  What’s wrong with removing the commands and adding shell aliases instead? That sounds perfectly reasonable to me. eg. In bash, they can be expressed as: alias fgrep=grep -F alias egrep=egrep -E This sounds like a push for purity - similar to what happened in Python 3 with the move from print “xyz” (special keyword) to print(“xyz”) (standard function). The new function requires three additional keystrokes every time it is used.
  • zorked 4y ago
    It breaks my script that calls /usr/bin/fgrep
• henearkr 4y ago
  They (the maintainer) should make the behavior of `grep` depending on the name of the executable. Then one could simply do a `ln -s grep egrep` and be done with it.
  • barrkel 4y ago
    That's exactly what it does already. The maintainers are objecting to the existence of the links.
    • henearkr 4y ago
      Yep. Almost (it uses a wrapper script instead of a symlink), but it ends up being such a silly situation all the same... Thanks for pointing it out though, I was not aware!
      • henearkr 4y ago
        I cannot edit anymore, so I add this: This is the case in a distribution (Arch) that has effectively taken the maintainer's advice into account, not the reverse.
• Pxtl 4y ago
  I do wish that there was a standard pipeline for warnings, so stuff like this didn't have to go into error (bad) or output (worse). Powershell has such a feature but of course since it's not at the OS/Posix level then support is spotty.
  • bitofhope 4y ago
    You can technically pipe to streams other than &1 and &2, so you could use printf "WARNING: %s" "$warn_msg" >&3 But of course, nonstandard.
  • int_19h 4y ago
    Why is it bad for it to go stderr? It's supposed to be used for all kinds of app meta-output, not just errors. If you want to actually check if the command failed, that's what exit codes are for. I did run into some Node.js code that assumed that anything printed out to stderr is a fatal error - but that's just people making wrong assumptions, not using the interface as intended.
• kwhitefoot 4y ago
  Sounds like a non-story to me. fgrep and egrep have been deprecated for nearly fifteen years and anyone who wants the old behaviour has only to create a couple of simple script files. Any distro that wants to can easily maintain such things.
• drewg123 4y ago
  I 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 root wheel 30736 Sep 26 14:37 /usr/bin/fgrep 281835 -r-xr-xr-x 4 root wheel 30736 Sep 26 14:37 /usr/bin/grep 281835 -r-xr-xr-x 4 root wheel 30736 Sep 26 14:37 /usr/bin/rgrep
  • Izkata 4y ago
    I didn't check where they came from, but on Ubuntu 18.04: egrep, fgrep, and rgrep are shell scripts that call grep with -E, -F, and -r
    • drewg123 4y ago
      On FreeBSD, it checks the first character of the program name and modifies behavior based on that. See https://github.com/freebsd/freebsd-src/blob/main/usr.bin/grep/grep.c#L327 https://github.com/freebsd/freebsd-src/blob/main/usr.bin/gre...
  • koprulusector 4y ago
    Thanks for sharing. I feel less silly for suggesting this now (as root): unalias grep && unalias egrep && cp "$(command -v grep)" "$(dirname "$(command -v grep)")/egrep
    • froh 4y ago
      why no hard link?
  • kevans91 4y ago
    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.
• Poiesis 4y ago
  As a software developer, I have long-since ingrained the behavior of looking up the documentation before I assume something works in a particular way. Perhaps doubly so when shell scripting, where I have to verify if I can rely on a particular package being present, or the minimum version of something I can expect, or what the output is guaranteed to be. When I was considering using fgrep, I looked it up; lo and behold, it's not part of the POSIX standard. So I used the option instead, and have since. I'm a little puzzled why people have problems with these little things when it feels like it's pretty common for tools to change given enough time (for example, ifconfig and netstat to ip and ss). It's just essentially an API that gradually refines over time.
  • barrkel 4y ago
    It's not that common for tools that have been around for decades, and don't have system dependencies (like your network configuration examples do) to change. egrep and fgrep are used on ad hoc command lines daily, and option alternatives are less convenient to use. I personally use 'egrep -o' and 'fgrep -f <(...)' all the time. I already find it tedious to have to type 'sed -r' and am half-considering wrapping it in an 'esed' variant. Eliminating egrep and fgrep is change for the sake of change. Removing a couple of hard links from a few bin directories would be the total positive achievement, at the cost of years of work removing the utilities from scripts - or more likely, adding the links back, or variants thereof, like shell scripts which add -E / -F as required.
• kristjank 4y ago
  GNU Grep manpage says: 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. Considering how drastically GNU departs from the bare POSIX interface in some of their tools, I find it strangely pedantic how the maintainers hold up the standard in this specific case. Considering the Linux mantra of "Never Break Userspace", I can't find a good reason to drop the binaries (or the script equivalents of calling grep -E/-F) besides uprooting a historical choice that never hurt anybody (with little benefit and a plethora of potential consequences) in the name of better-late-than-never correctness.
  • javier_e06 4y ago
    GNU: GNU is Not Unix. Or Linux for that matter.
  • froh 4y ago
    somehow the opengroup removed egrep and fgrep from POSIX in 2018 https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu... chroot, usefull for poor man's containment of 'stuff' also went out. and they replaced tar with pax --- which uses a tar file format one of the things I love in Unix is the slow pace of evolution in systems tools. relevant know how doesn't rot as fast as in other environments.
• radford-neal 4y ago
  I 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 be far outweighed by the time wasted debating this issue), these scripts will no longer work. There is no guarantee that defining an alias somewhere is going to fix all your usages of fgrep. And even if it did, the cost for every single installation that is affected of someone realizing there is a problem, finding the source of the problem, figuring out that an alias will fix it, making sure that that alias gets preserved after updates, and testing that everything now works will exceed the benefit to the maintainers of grep (which is actually negative, as explained above). So looked at from a community-wide perspective, the cost is many thousands of times greater than any possible (but actually non-existent) benefit. And as the post mentions, there are also all the books, and all the stackoverflow answers, that use fgrep, and which will now have non-working code. As for the argument that this is open-source software maintained by volunteers, who can therefore do whatever they wish - if you are a maintainer of widely-used open-source software, and decide that you personally are not interested in working in a manner that benefits the community of users, then you should resign and let someone else take over.
  • barrkel 4y ago
    There's a certain type of person who gets pleasure from following rules exactly, particularly when other people don't follow those rules. A kind of smug moral superiority. If they get into a position of power, they can make life worse for other people, without much regard for the actual cost of breaking such rules. Removing egrep and fgrep is desperately petty stuff.
    • PaulHoule 4y ago
      It’s a show of how free software partisans are often out of touch. The cost of egrep and fgrep is just two symbolic links. Some people though would rather talk about ‘libre’ and ‘free as in speech’ and ‘free as in beer’ than talk at all about the user experience. And they wonder why most people just run windows or macOS, but they’ll never understand.
• nickcw 4y ago
  If you want modern regexp syntax then forget egrep/grep -E and use grep -P for Perl Compatible Regular Expressions. PCRE is the most commonly used regex syntax for modern programming languages, eg Python, Go (mostly) etc and grep -P will save lots of annoyance if you use one of these!
  • tolciho 4y ago
    The -P is not for portability. $ grep -P foo grep: unknown option -- P
• xani_ 4y ago
  grep -P is only true way
  • gjvc 4y ago
    grep --perl-regexp --only-matching pattern some/where/file/name aka grep -Po pattern some/where/file/name
• jmclnx 4y ago
  Here is what I gave for 'fgrep' on Slackware 15: cat /bin/egrep #!/bin/sh exec grep -E "$@" Is that really hard to maintain :) I was expecting to see a link, but instead it is a shell script GNU is asking is to create. I do not know why GNU says that is hard to maintain going forward. BTW, this is grep v3.7
• waffletower 4y ago
  It is depressing, even sickening how common such exercises in tunnel-vision vigilantism occur among software engineers. The same lack of understanding of downstream impacts is found in library maintainers that use auto-updating transitive dependencies, for example.
• bitofhope 4y ago
  >I'm definitely not in favor of fossilizing Unix, but there's a difference between avoiding fossilization and the kind of minimal, mathematical purity that we see GNU Grep trying to impose here. I can't really see the difference. Adding a deprecation warning to stderr in a non-POSIX command 15 years after deprecation notice is among the smallest possible changes to [GNU's Not] Unix I can think of. Even then, the change is trivially silenced by deleting a single line in a shell script or two[1] and seems that some distros already do that for you[2]. Yes, this will break something for someone[3] and I might well be that someone. You truly have my sympathies. But if you want to run a system for a decade and a half without ever needing changes, stick to POSIX. You can't have your fossils and eat them too. [1] https://git.savannah.gnu.org/cgit/grep.git/commit/src/egrep.sh?id=a9515624709865d480e3142fd959bccd1c9372d1 https://git.savannah.gnu.org/cgit/grep.git/commit/src/egrep.... [2] https://github.com/void-linux/void-packages/pull/39340 https://github.com/void-linux/void-packages/pull/39340 [3] https://xkcd.com/1172/ https://xkcd.com/1172/
  • acdha 4y ago
    > But if you want to run a system for a decade and a half without ever needing changes, stick to POSIX. You can't have your fossils and eat them too. … and test before making major system upgrades. For most users this won't be arriving until the next major distribution release and it seems unlikely that this will be the only visible change in such a move. If it's that big a deal, you should have a test environment, change management, dedicated admins, etc.
• aftbit 4y ago
  On my system, egrep and fgrep are _already_ shell scripts, just changed to add the stupid warning: $ cat =egrep =fgrep #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -E" >&2 exec grep -E "$@" #!/bin/sh cmd=${0##*/} echo "$cmd: warning: $cmd is obsolescent; using grep -F" >&2 exec grep -F "$@" Looking at src/egrep.sh in the git repo[1], I see that before this warning was added in 2021, the last change was back in 2015. In fact, since the git repo history began in 1998, there have been a total of 4 changes to this file. Clearly the maintenance burden of these scripts is not sufficient to require the maintainers to drop them. My guess... this is being done out of some weird sense of purity over practicality. Bad call by Paul Eggert IMO[2]. 1: https://savannah.gnu.org/git/?group=grep https://savannah.gnu.org/git/?group=grep 2: commit a9515624709865d480e3142fd959bccd1c9372d1 added the warnings
  • yjftsjthsd-h 4y ago
    > cat =egrep =fgrep What is that? I can't seem to find it by searching for " =" in `man bash`
    • professoretc 4y ago
      In ZSH `=executable` expands to the full path of `executable`.
    • deleted 4y ago
      [deleted]
    • pwagland 4y ago
      This is a zsh thing, it's shorthand for: cat "$(which egrep)" "$(which fgrep)"
    • deleted 4y ago
      [deleted]
    • sprremix 4y ago
      It's a zsh thing. 14.7.3 ‘=’ expansion If a word begins with an unquoted ‘=’ and the EQUALS option is set, the remainder of the word is taken as the name of a command. If a command exists by that name, the word is replaced by the full pathname of the command. From: https://zsh.sourceforge.io/Doc/Release/Expansion.html#g_t_0060_003d_0027-expansion https://zsh.sourceforge.io/Doc/Release/Expansion.html#g_t_00...
• mrybczyn 4y ago
  Tool devs should get to decide on functionality - and then it's up to the distro maintainers to make aliases and organize well into their distros. Here it seems that the former are encroaching on the latter, for historical reasons? By the way: ~$ bgrep Command 'bgrep' not found, but there are 20 similar ones. There's not many [a-z]grep's left in the alphabet, reserve yours now :-)
• robertlagrant 4y ago
  > (I'm definitely not in favor of fossilizing Unix, but there's a difference between avoiding fossilization and the kind of minimal, mathematical purity that we see GNU Grep trying to impose here. I'm not sure this can be reconciled with "printing a deprecation warning is a breaking change".
• L1fescape 4y ago
  GNU Grep: "Am I so out of touch? No, it's the users who are wrong"
• hnlmorg 4y ago
  There 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=src/egrep.sh;h=a0d1694eccb00943322fc561f4f26dbf979a22ad;hp=6d6c15a84cfea465055bf258afe88404350162fd;hb=a9515624709865d480e3142fd959bccd1c9372d1;hpb=e87ccc7038d4f44f4601b3e8775fef09b1420dff 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 the former requires extra forks() compared to the latter. However I'd counter that advice saying "if you're concerned about the performance of forks() then why are you running your code as a shell script to begin with?"... and I stand by that assessment now. In fact it would probably take me longer to type `-E` than it would for any modern system to run fork() (and I'm sure as hell not planning on using `grep` inside any hot loops!) I think what will likely happen here is that distro maintainers will either remove that warning themselves or take ownership of the `egrep` and `fgrep` shell scripts. I'd be surprised if that warning made its way to the mainstream distros. I also wouldn't be surprised if the GNU grep maintainers did a u-turn on this change -- though it has already been committed to git for more than a year now and this is the first I've heard people complain about the change.
  • tomn 4y ago
    the overhead isn't even an extra fork, as it uses exec
    • hnlmorg 4y ago
      Good point. Though invoking $SHELL and parsing the script (as short as it is) can't be cheap either. Academically speaking of course; I'm not trying to justify the change on performance grounds.
    • txutxu 4y ago
      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 Measured with "time" 0m0.002s Vs 0m0.003s, always, testing 4 times each option. Most situations where it could be being used, probably are surrounded by much bigger optimizations to work on.
• gjvc 4y ago
  see also: which being deprecated, replaced by: command -v
• dahart 4y ago
  The article and very few comments acknowledge that this is being done to facilitate removal of these binaries. Assuming the binaries are going away, is it better to add a warning, or to surprise people be just removing them? In general, there’s a good, legitimate, hard question here about how to handle removing things from our software. It needs to be done, probably more often than we do it, and it’s hard enough for software writers and maintainers to bring themselves to remove things. Are there better strategies? What more can we do to make removing features less painful, beyond publishing the deprecation schedule, adding a warning in advance, and then removing them after the schedule and the warning have been out for a while?
  • kevincox 4y ago
    I don't think most of the comments are worrying about the difference between warning or removal. Most of the comments are about what is wrong with egrep continuing to work perfectly well as it has for a decade without warning or being removed.
• kentonv 4y ago
  Some context: egrep and fgrap are implemented as wrapper scripts that look like this: #!/bin/sh exec grep -E "$@" 28 bytes. Now consider the cost/benefit between two options: 1. Maintain these wrapper scripts forever. 2. Update all scripts in the world that use these to use the flags instead, eventually removing the wrappers. What is the cost of option 1? It's essentially zero. No changes means no engineering work. Some hard drive space is wasted, but TBH you can probably buy a single hard drive with enough capacity to store all copies of these files that will ever exist. Perhaps some people's sense of cleanliness will be offended by the continued existence of non-standard commands but it's hard to demonstrate any actual cost from that. What is the cost of option 2? Many thousands of hours of engineering labor, just to update scripts. But that's just the beginning: There will likely be production outages when the script are finally removed, since inevitably some uses will be missed. That will cost money. It will also lead to a general increase in fear of software updates, leading even more people to run outdated installations that are vulnerable to security flaws. Security breaches will cost more money. It seems clear this change will cost millions of dollars, whereas keeping things as they were would have trivial cost. Therefore, this change should not have been made, and should be reverted. Reasoning like this is why widely-used platforms simply never remove "deprecated" APIs: * Java still contains APIs deprecated 25 years ago in version 1.1. * Linux's ABI is famously stable, with Linus verbally abusing anyone who even suggests a backwards-incompatible change. (I don't approve of the abuse part.) * The web platform is backwards-compatible even with objectively bad JavaScript design decisions made by Netscape in the 90's. * C libraries still include `gets()` even though any use of it implies a security vulnerability. (Though we hope any remaining users are not running in security-sensitive use cases...) * The Windows API is full of trash but you can still run executables built in the 90's. "Deprecated" was never supposed to mean "will go away". It was always supposed to mean only "there's a better way to do this".
  • jeroenhd 4y ago
    If the GNU folks want to remove the wrapper scripts, they can. It's their software and they write the best practices for it. Distro maintainers can still ship these scripts. They can add aliases to the user profile to do the same thing without having to launch a sh instance. Maybe they'll add a second package, grep-utils, that just contains the wrapper scripts so you can choose between GNU's position and the "I don't like change" position. Microsoft has deprecated and removed tons of stuff and so did browsers. Vista crashed so often because Microsoft did away with their entire driver model and vendors wrote quick wrappers around their old, crappy drivers and shipped those. Many remaining browser features are reasons why web development sucks so much ("quirks mode" for one) and Java not breaking compatibility has given it many problems that dotnet solved by breaking compat once. Java also has removed several deprecated packages and moved them to libraries instead (like Nashorn). Deprecated means "if we see a reason to remove this, we may remove this in the future". It's no guarantee for removal but it's no guarantee for being kept around either.
• cies 4y ago
  I'm on ripgrep (Rust, very fast). Thanks BurntSushi!
  • adren67 4y ago
    I completely agree that rg/ripgrep is a way better alternative to most grep implementations including GNU grep not only in terms of feature check https://beyondgrep.com/feature-comparison/ https://beyondgrep.com/feature-comparison/ for a detailed comparison but also in terms of speed, including the fact that ripgrep allows greping by default in compress files, many different encoding and more! This software is really a must-have for anyone who spends some time on the CLI
    • Communitivity 4y ago
      I also use ripgrep, and swear by it. It has many of the features previously only found in ag or git grep (parallelism, respect .ignore files, search hidden files, etc). It's old, but here'd a feature comparison of ag, git grep, ripgrep and others: https://beyondgrep.com/feature-comparison/ https://beyondgrep.com/feature-comparison/
• chrismarlow9 4y ago
  I started to get really passionately angry about this because I am an fgrep user. Then I realized I can avoid my blood pressure spiking by just running a one liner and making a few edits. The muscle memory might take a while to fix but I'll be better for it and avoid my day starting off with anger about trivial things. sudo grep -rF 'fgrep' / 2>fgrep.rip.stderr.log | tee fgrep.rip.log Goodbye old friend...
• superkuh 4y ago
  Old software remains stable and usable. Updates break software, remove features, and introduce new exploits. I'll stick with the old reliable.
• p4bl0 4y ago
  I see the problem for scripts, but for people it's just a matter of setting an alias command, isn't it?
• rrwo 4y ago
  I've started to wean myself off of `fgrep`, but only because I am using `zgrep -F` as I'm often searching through logs, which may or may not be gzipped. But this is a stupid change.
• bravetraveler 4y ago
  Just, why? Change for the sake of being noticed? Not getting enough attention at home? Countless tools have figured out how to argv[0] or whatever - the path of the binary changing the behavior
• chubot 4y ago
  BTW I ONLY use egrep and fgrep !!! - egrep means [0-9]+ works like in Perl/Python/JS/PCRE/every language, not [0-9]\+ like GNU grep. - egrep syntax is consistent with bash [[ $x =~ $pat ]], awk, and sed –regexp-extended (GNU extension) - These are POSIX extended regular expressions. Awk uses them too. - `fgrep` is useful when I want to search for source code containing operators, without worrying about escaping This style makes regular expressions and grep a lot easier to remember! I want to remember 2 regex syntaxes (shell and every language), not 3 (grep, awk, every language) ! This change should be reverted; there is no point to needless breakage Again you wouldn’t remove grep –long-flags because it’s not POSIX
  • blep_ 4y ago
    You may also be interested in `grep -P`, where `P` is short for `Please just use PCRE like everything else in this century`. I don't think any of the others support that though.
• teddyh 4y ago
  The GNU tools and programs are, theoretically, created for the GNU system, which has evidently chosen to (eventually) not provide fgrep and egrep, as they are not part of the POSIX standard. This is the GNU project’s choice to do. Other operating system projects, like Debian GNU/Linux, who use the GNU tools to provide their operating system, might choose otherwise and (separately) provide the fgrep and egrep tools. This would then be their choice (and one that I personally expect them to make). I.e. if you don’t run straight GNU as your OS, don’t complain about this; instead object if your operating system which you actually use or depend on choose to break behavior and interfaces which your programs rely on.
• richard_todd 4y ago
  It's interesting to think about the way these things evolved. Imagine if, over time, the `compress` utility got -gz, -bz2, -lzma, etc. flags, and `gzip`/`bzip2` were all converted to deprecated shell scripts. When is the right time to consolidate variants under one program (and deprecate the variants), and when is it better to let small utilities keep doing one thing well(TM)? I see people talking about removing the compatibility scripts being driven by a sense of purity, but wasn't it that same sense of purity driving someone to collapse `fgrep` and `egrep` into `grep` in the first place? The sense that these are all just variants of the same goal, and thus should be flags to the same program? Why bother combining them if not to ultimately remove the "extra" programs one day? I'm not sure what the right answer is. On one hand, I like the idea of a smaller namespace of programs with a larger set of well-documented switches. The alternate universe where `compress` covers the widely-used variants of compression and the variant utilities fell away over time sounds kind of nice. Or imagine if early UNIX had arrived at a "plugin" model, where top-level programs like grep should have pluggable regex engines which can be provided by independent projects? The culture we have, of tiny independent projects, will always make consolidation and deprecation messy events.
  • mirker 4y ago
    As someone who learned about regular expressions before extensively using grep, I found grep to be quite unintuitive, since extended grep is what I am conceptually thinking about from a “theory” point if view. One difference between grep and compression is that grep is bounded by regular languages, but compression is more free form. It’s conceivable to therefore view grep as mature enough of a technology to be finished once and for all, but compression will continue branching into many disparate algorithms.
    • richard_todd 4y ago
      Consider the popularity of ffmpeg and imagemagick. Putting the mainstream algorithms together under one interface seems to be an appealing model to a lot of people, even though new algorithms are constantly being developed in those areas. Personally, for audio encoding, I'm much happier just installing ffmpeg than I would be gathering and learning a bunch of flac/ogg/opus/mp3/etc encoders.
• xt00 4y ago
  I guess they backed out the “which” change before this so you wouldn’t see something silly like: which egrep And it would print You should use command -v egrep is being deprecated /usr/.. Like jeez..
• manv1 4y ago
  This only affects linux. All the old AIX/SunOS/Solaris/HP-UX boxes will never get this update, so luckily it should have 0 effect on older platforms. That makes me feel better, that all the old crap that I've forgotten about that might be running in production somewhere will be fine. That said, this is a ridiculous move. The only practical effect of this change is to potentially break millions of scripts, all for an ideal that, to be frank, nobody gives a shit about.
• radford-neal 4y ago
  Beyond the inadvisability of making a breaking change for no reason, it's worth noting that deprecating fgrep is actually positively undesirable. Use of fgrep should be encouraged. The reason is that many times people want to match a literal string. This is best done with, for example, "fgrep [a] <file". Note that this is not the same as "grep [a] <file", since '[' has special meaning in regular expressions. Of course, you can write "grep \\[a] <file", but not everyone has the set of special characters used for regular expressions at the top of their mind. Of course, one could get in the habit of using grep -F when intending the pattern to be just a literal string. Or one could write one's own fgrep shell file. But both of these options require more effort than just using fgrep. One aim of good design should be to make it easy to do things in the reliable way. That way it's more likely to be done.
  • teddyh 4y ago
    If we are talking about interactive use, you could always use an alias. But if we are talking about scripts, you should at least use "fgrep -- [a] < file". And if you’re adding an option anyway, you might as well use "grep -F -- [a] < file". Personally, I prefer using options, specifically long options, in scripts; meaning "grep --fixed-strings --regexp=[a] < file". If you don’t do this, the script will fail spectacularly the day when the string happens to start with a hyphen (-).
    • romeoblade 4y ago
      I thought I was the only one who perfected long options! Are you me? I've had coworkers call me out (not rude, just "hey you know you just use -l... instead of --longopt") on calls because I always use long options when available. I use the hyphen explanation all the time as I've ran into it a few times. I also prefer CLI applications that are designed to use the "=" for arguments with long options. Applications which don't use "=" or respect it, irk me because the it's ambiguous... "Is that argument an argument or sub command" when looking through history.
      • teddyh 4y ago
        I don’t always use long options interactively, only sometimes, but I certainly try to always use it in scripts, for readability.
• cryptonector 4y ago
  > What's special about GNU Grep 3.8 is that its version of egrep and fgrep now print an extra message when you run them. Specifically, these messages 'warn' (ie nag) you to stop using them and use 'grep -E' and 'grep -F' instead. Can we please stop with the make-work nonsense?? Please stop making us change scripts just because you've decided that some command shouldn't have existed that does exist. Stop it. Just stop. See `which` deperecation. Please, no more.
  • deleted 4y ago
    [deleted]
• Asooka 4y ago
  It's probably time for the Linux world to distance itself from the trash fire that is GNU, as they keep breaking backwards compatibility. This isn't 1970, it's 2022, people! You do not just break the world for no good reason. GNU has served its purpose, it's time to stop relying on them. It would be a lot easier to convince the BSD people to support the few GNU specific flags in user land utilities and to add GNU libc compatibility, than it would be to convince the GNU maintainers to write good software.
• throw10920 4y ago
  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.
• ngvrnd 4y ago
  I like beating people in concept but not in practice.
• shmerl 4y ago
  ripgrep (rg) is an option. I switched to it for all my grepping needs.
• manv1 4y ago
  It's ironic that GNU is using POSIX as a justification for a decision. From RMS: Following a standard is important to the extent it serves users. We do not treat a standard as an authority, but rather as a guide that may be useful to follow. Thus, we talk about following standards rather than "complying" with them. See the section Non-GNU Standards in the GNU Coding Standards. We strive to be compatible with standards on most issues because, on most issues, that serves users best. But there are occasional exceptions. For instance, POSIX specifies that some utilities measure disk space in units of 512 bytes. I asked the committee to change this to 1K, but it refused, saying that a bureaucratic rule compelled the choice of 512. I don't recall much attempt to argue that users would be pleased with that decision. Since GNU's second priority, after users' freedom, is users' convenience, we made GNU programs measure disk space in blocks of 1K by default. https://opensource.com/article/19/7/what-posix-richard-stallman-explains https://opensource.com/article/19/7/what-posix-richard-stall...
• markhahn 4y ago
  preach!
• kcexn 4y ago
  I'm so confused by this change. fgrep and egrep are already just shell scripts that are almost just like aliasing grep -E and grep -F. Why is the GNU team suddenly so worried about these shell scripts? If the maintenance of these scripts is so hard. They could just deprecate them entirely. It's pretty unlikely that they would stop working or become insecure anytime soon. And sysadmins would just source in the aliases into their shell environments anyway....
• forty 4y ago
  While we are discussing common command aliases, could we decide to make ll (= ls -l) a standard one? I have a hard time using a shell without it, and it's annoying to create the alias on all the machines I ssh to ^^
• dschuetz 4y ago
  Seriously, what's the deal? Just use aliases instead, if you're fond of using egrep or fgrep yourself. Refactoring and re-deploying scripts should not be a big issue in any environment either these days. Admin/Devs are lazy, yes. But THAT is the least of their problems maintaining shell scripts.
• Jenda_ 4y ago
  I first thought about different warning that GNU grep >= 3.8 emits: about "stray \" (it's also in the changelog - https://lists.gnu.org/archive/html/info-gnu/2022-09/msg00001.html https://lists.gnu.org/archive/html/info-gnu/2022-09/msg00001...). I have personally seen this one several times already and I only have grep 3.8 on my desktop, as I use Debian stable everywhere else. But this warning may prevent hidden bugs in the future.
• nullc 4y ago
  Just be glad they haven't handed over maintenance to the gnome project.
  • kps 4y ago
    Soon grep will be a systemd module.
    • ykonstant 4y ago
      Surely you mean systemd-grepd -z nuts
• arrakeen 4y ago
  debian appears to be just removing the warnings: grep (3.8-2) unstable; urgency=low This Debian grep release removes the deprecation warning about egrep and fgrep. These alternative programs will be still shipped by Debian. Although, for portability reasons, users are encouraged to use grep with the concerned options instead of those alternative programs.