47 ms·

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 br

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.
  - gumby 4y ago
    > The cost of egrep and fgrep is just two symbolic links. A cost that needs to be paid every time you invoke them (a double lookup in the filesystem). Just use a regular link. (I felt a pedantic response would be in the spirit of this change by the GNU project).
    - Maursault 4y ago
      > > The cost of egrep and fgrep is just two symbolic links. > A cost that needs to be paid every time you invoke them (a double lookup in the filesystem). Just use a regular link. I'm having a bit of trouble understanding the outrage. Can't all egrep/fgrep in all scripts be fixed once in one or two commands and remain fixed? $ sed -i 's/fgrep/grep\ -F/' *.sh (or something) I see it as getting accustomed to bells and whistles on some modern shell (like tab completion on zsh and others), then having to use a shell on another system without them (some ragged old korn) and getting tripped up... and the ultimate solution is to be conscious that these things don't work everywhere, so don't be too reliant on them.
      - gumby 4y ago
        How would you find every script given that people download all sorts of scripts all the time? What about docker images? And that doesn't even open the can of worms relating to quoting...
        Maursault 4y ago
        If we don't know where our scripts are, we have much deeper issues, but still not insurmountable. $ sed -i 's/fgrep/grep\ -F/' $(grep -rw '/' -e 'fgrep') (or something) I don't manage docker images, but surely there must be a way to do something as simple as replace a file in one image,[1] and if that can be done, doing so in all images is just one clever step away. [1] https://stackoverflow.com/questions/40895859/how-can-i-overwrite-a-file-through-dockerfile-in-docker-container https://stackoverflow.com/questions/40895859/how-can-i-overw...
  - 4y ago
- gnfargbl 4y ago
  If you look at the POSIX standard that removes fgrep & egrep [1], then you can see that most of the utilities being removed there really are quite obscure things. In light of that, then another (perhaps more charitable) way to look at it is that the maintainers are keen to clean up stuff that they perceive as old cruft, and perhaps don't realise quite how ingrained these particular pieces of "cruft" are into the ecosystem. (On the other hand: the same POSIX link specifies the removal of cpio and, uh, tar. I'm not sure I see that last one flying.) [1] https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu...
  - jws 4y ago
    ”removal of cpio and, uh, tar” They’ve finally figured out how to make people use pax.
  - wnissen 4y ago
    No `tar`? BURN. IT. ALL. DOWN. Dear God, what could they possibly be thinking? People are capable of making changes, I think we've all switched from `more` to `less`, *csh to more modern shells, etc., and if `pax` is really all that I'm happy to switch. But removing tar is insane.
- MichaelCollins 4y ago
  The worst is when the rule they cite isn't a real rule at all, like Lennart Poettering's defense of systemd breaking on usernames starting with a digit, which is completely valid as far as the Linux kernel is concerned but he decided such names were ackshully against the rules and therefore systemd wasn't broken, bug report closed not-a-bug.
- cryptonector 4y ago
  We've seen a lot of this in recent years.
- paulmd 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. HN commenters in a nutshell. Not you in particular, but oh my god, the rules-lawyering and lecturing on this site is unbearable at times.
Cthulhu_ 4y ago
I mean they could just make it an alias that calls the appropriate grep function, and mention fgrep/egrep are just aliases in all the documentation. Tools like ShellCheck could warn on use of fgrep/egrep in scripts in favor of grep if it wants things to be pure. But the cost of keeping an alias around for decades is negligible I think. It's cheaper than breaking every existing usage in any case.
pfortuny 4y ago
This is exactly why Torvalds is so radical on not regressing: it is costly for him (I am sure there are many things hr would have done differently now) but ensures the users’ security.
thomastjeffery 4y ago
I find it amusing that someone who uses fgrep all the time - and is presumably familiar with alias and sed - would be worried about the inconvenience of updating their shell scripts... I think the larger issue is that people generally don't do dependency management for their scripts. Scripts are programs, and they are dependent on the shell environments they are written for.
- radford-neal 4y ago
  I think you're not grasping the point that the cost of using 'alias' or updating scripts, though not huge, is paid by every single user, and often over and over again, every time they switch to using a different system. Against this cost for every user, one weighs the benefits of this change - which are zero. Indeed, the benefits are negative, since the maintainers must surely be wasting more time debating the change than they will ever save from it. Of course, scripts are dependent on their environment. That's why changing the environment for no reason is such a bad idea. Nobody manages their shell scripts to account for the possibility that 'true' might cease to exist some day...
  - thomastjeffery 4y ago
    > the cost of using 'alias' or updating scripts, though not huge, is paid by every single user, and often over and over again The cost of a change that effects N users is paid by N users. user*N - change*N = user - change The amount of work each person must do is not increased by the amount of work everyone else most do. > Against this cost for every user, one weighs the benefits of this change - which are zero. That point specifically I am not arguing with. I agree this change doesn't seem to have merit. Remember: I am not the one imposing it on you. Deprecating fgrep in a grep package distribution is just like deprecating a function in a library. The only reason it would be more difficult to handle that change is if you don't have a straightforward way of managing changes in your scripts and/or shell environments. And that's the point I was making: it's very common for shell scripts to exist in unmanaged - and frankly brittle - environments. That's a problem that is not unique to this situation. --- Here's an example: If someone deprecated the printf() function in gcc version 127.4, replacing it with print(format=False,...), then anyone using gcc 127.4 would have to make a straightforward change to their code. Would it be annoying and pointless? Yes, that's the criteria for this hypothetical situation. Would it be difficult to manage? No, not really. You would just update your gcc dependency version, find and replace printf, sanity check, commit, done. The reason deprecating fgrep is scary is that people tend to manage shell scripts more liberally. In other words, they likely aren't managed at all. Are they in a git repo? Who is running it? On what machine? What user? Critically, there probably isn't a clear way to predict what version of grep is going to be installed in what environment, and when. This isn't a new problem. Package maintainers diverge all the time on what binary names and aliases they provide. Tell me, if you opened a shell on any random GNU/Linux system you have access to, and typed "python", would it be version 2 or version 3? Would python3 be in the path? It's valuable to be able to manage these things. That's why projects like Nix are so popular.
hinkley 4y ago
> 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. As walled gardens begin to reassert themselves, I think this advice above will be the big argument in open source over the next ten years and needs to be written on every vertical surface. Either we will have social contracts in open source, or we will have commercial contracts. There will be diminishing examples of “both” and people will continue clutching their pearls about co-opting until something changes. “Be grateful you get anything” is good advice for people struggling to find their own peace of mind, but when it comes up in an argument that’s just abuse.
deleted 4y ago
[deleted]
kazinator 4y ago
If your reason for using fgrep is that grep -F is more characters longer, the logical thing would be to have your own function or alias which is called just f or fg. I stopped using egrep and fgrep in scripts ~25 years ago when I found out they weren't in the standard. grep -F is only useful when the pattern contains regex characters that should be treated literally, and since the default regex language of grep is BRE, those characters are few. If only one special character occurs you break even on character count if you use a backslash escape: fgrep 'a*c' grep 'a\*c'

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.
- gumby 4y ago
  > The cost of egrep and fgrep is just two symbolic links. A cost that needs to be paid every time you invoke them (a double lookup in the filesystem). Just use a regular link. (I felt a pedantic response would be in the spirit of this change by the GNU project).
  - Maursault 4y ago
    > > The cost of egrep and fgrep is just two symbolic links. > A cost that needs to be paid every time you invoke them (a double lookup in the filesystem). Just use a regular link. I'm having a bit of trouble understanding the outrage. Can't all egrep/fgrep in all scripts be fixed once in one or two commands and remain fixed? $ sed -i 's/fgrep/grep\ -F/' *.sh (or something) I see it as getting accustomed to bells and whistles on some modern shell (like tab completion on zsh and others), then having to use a shell on another system without them (some ragged old korn) and getting tripped up... and the ultimate solution is to be conscious that these things don't work everywhere, so don't be too reliant on them.
    - gumby 4y ago
      How would you find every script given that people download all sorts of scripts all the time? What about docker images? And that doesn't even open the can of worms relating to quoting...
      - Maursault 4y ago
        If we don't know where our scripts are, we have much deeper issues, but still not insurmountable. $ sed -i 's/fgrep/grep\ -F/' $(grep -rw '/' -e 'fgrep') (or something) I don't manage docker images, but surely there must be a way to do something as simple as replace a file in one image,[1] and if that can be done, doing so in all images is just one clever step away. [1] https://stackoverflow.com/questions/40895859/how-can-i-overwrite-a-file-through-dockerfile-in-docker-container https://stackoverflow.com/questions/40895859/how-can-i-overw...
- 4y ago
gnfargbl 4y ago
If you look at the POSIX standard that removes fgrep & egrep [1], then you can see that most of the utilities being removed there really are quite obscure things. In light of that, then another (perhaps more charitable) way to look at it is that the maintainers are keen to clean up stuff that they perceive as old cruft, and perhaps don't realise quite how ingrained these particular pieces of "cruft" are into the ecosystem. (On the other hand: the same POSIX link specifies the removal of cpio and, uh, tar. I'm not sure I see that last one flying.) [1] https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap04.html https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu...
- jws 4y ago
  ”removal of cpio and, uh, tar” They’ve finally figured out how to make people use pax.
- wnissen 4y ago
  No `tar`? BURN. IT. ALL. DOWN. Dear God, what could they possibly be thinking? People are capable of making changes, I think we've all switched from `more` to `less`, *csh to more modern shells, etc., and if `pax` is really all that I'm happy to switch. But removing tar is insane.
MichaelCollins 4y ago
The worst is when the rule they cite isn't a real rule at all, like Lennart Poettering's defense of systemd breaking on usernames starting with a digit, which is completely valid as far as the Linux kernel is concerned but he decided such names were ackshully against the rules and therefore systemd wasn't broken, bug report closed not-a-bug.
cryptonector 4y ago
We've seen a lot of this in recent years.
paulmd 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. HN commenters in a nutshell. Not you in particular, but oh my god, the rules-lawyering and lecturing on this site is unbearable at times.

Cthulhu_ 4y ago

I mean they could just make it an alias that calls the appropriate grep function, and mention fgrep/egrep are just aliases in all the documentation. Tools like ShellCheck could warn on use of fgrep/egrep in scripts in favor of grep if it wants things to be pure. But the cost of keeping an alias around for decades is negligible I think. It's cheaper than breaking every existing usage in any case.

pfortuny 4y ago

This is exactly why Torvalds is so radical on not regressing: it is costly for him (I am sure there are many things hr would have done differently now) but ensures the users’ security.

thomastjeffery 4y ago

I find it amusing that someone who uses fgrep all the time - and is presumably familiar with alias and sed - would be worried about the inconvenience of updating their shell scripts... I think the larger issue is that people generally don't do dependency management for their scripts. Scripts are programs, and they are dependent on the shell environments they are written for.

radford-neal 4y ago
I think you're not grasping the point that the cost of using 'alias' or updating scripts, though not huge, is paid by every single user, and often over and over again, every time they switch to using a different system. Against this cost for every user, one weighs the benefits of this change - which are zero. Indeed, the benefits are negative, since the maintainers must surely be wasting more time debating the change than they will ever save from it. Of course, scripts are dependent on their environment. That's why changing the environment for no reason is such a bad idea. Nobody manages their shell scripts to account for the possibility that 'true' might cease to exist some day...
- thomastjeffery 4y ago
  > the cost of using 'alias' or updating scripts, though not huge, is paid by every single user, and often over and over again The cost of a change that effects N users is paid by N users. user*N - change*N = user - change The amount of work each person must do is not increased by the amount of work everyone else most do. > Against this cost for every user, one weighs the benefits of this change - which are zero. That point specifically I am not arguing with. I agree this change doesn't seem to have merit. Remember: I am not the one imposing it on you. Deprecating fgrep in a grep package distribution is just like deprecating a function in a library. The only reason it would be more difficult to handle that change is if you don't have a straightforward way of managing changes in your scripts and/or shell environments. And that's the point I was making: it's very common for shell scripts to exist in unmanaged - and frankly brittle - environments. That's a problem that is not unique to this situation. --- Here's an example: If someone deprecated the printf() function in gcc version 127.4, replacing it with print(format=False,...), then anyone using gcc 127.4 would have to make a straightforward change to their code. Would it be annoying and pointless? Yes, that's the criteria for this hypothetical situation. Would it be difficult to manage? No, not really. You would just update your gcc dependency version, find and replace printf, sanity check, commit, done. The reason deprecating fgrep is scary is that people tend to manage shell scripts more liberally. In other words, they likely aren't managed at all. Are they in a git repo? Who is running it? On what machine? What user? Critically, there probably isn't a clear way to predict what version of grep is going to be installed in what environment, and when. This isn't a new problem. Package maintainers diverge all the time on what binary names and aliases they provide. Tell me, if you opened a shell on any random GNU/Linux system you have access to, and typed "python", would it be version 2 or version 3? Would python3 be in the path? It's valuable to be able to manage these things. That's why projects like Nix are so popular.

hinkley 4y ago

> 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. As walled gardens begin to reassert themselves, I think this advice above will be the big argument in open source over the next ten years and needs to be written on every vertical surface. Either we will have social contracts in open source, or we will have commercial contracts. There will be diminishing examples of “both” and people will continue clutching their pearls about co-opting until something changes. “Be grateful you get anything” is good advice for people struggling to find their own peace of mind, but when it comes up in an argument that’s just abuse.

deleted 4y ago

[deleted]

kazinator 4y ago

If your reason for using fgrep is that grep -F is more characters longer, the logical thing would be to have your own function or alias which is called just f or fg. I stopped using egrep and fgrep in scripts ~25 years ago when I found out they weren't in the standard. grep -F is only useful when the pattern contains regex characters that should be treated literally, and since the default regex language of grep is BRE, those characters are few. If only one special character occurs you break even on character count if you use a backslash escape: fgrep 'a*c' grep 'a\*c'