2 ms·

Either a system is frozen and static, in which case it will not receive this version of GNU grep, and there is no problem. On the other hand, if a system recei

by teddyh 4y ago

Either a system is frozen and static, in which case it will not receive this version of GNU grep, and there is no problem. On the other hand, if a system receives updates, the system needs both minor and major changes all the time, to keep up with its ever-changing environment. This is the jungle in which we live. Linux syscalls are important to keep, since it’s hard to change a compiled binary. But it’s easy to change a shell script. And don’t exaggerate. This won’t, in all likelihood, “break” your scripts.

simoncion 4y ago
> This won’t, in all likelihood, “break” your scripts. Previously: > The first option is to simply replace "fgrep" with "grep -F" everywhere in all your scripts, which is correct but is more work than your other option, which is to add your own "fgrep" script somewhere in your path. script.sh: line 100: fgrep: command not found seems like evidence of a broken script to me. The fact that it can be fixed doesn't make it not broken.
- teddyh 4y ago
  We were discussing the warning printed by fgrep and egrep, not their removal. I was suggesting that you put a version of fgrep/egrep in your path which does not show the warning.
  - ajross 4y ago
    That wasn't my take. I thought we were discussing the deprecation itself. It's true that nothing is broken yet[1]. But it's clear that "broken" is where we're going, and I don't think you or the GNU maintainers have thought through the implications correctly. [1] At least, nothing that isn't sensitive to junk on stderr -- bourne scripts are not always as tolerant as you'd like.
    - teddyh 4y ago
      We were explicitly discussing GNU grep 3.8, which does not remove anything, only add warnings. And the remote possibility of breakage due to warnings is why I qualified my assertion with “in all likelihood”.

2 ms·

Either a system is frozen and static, in which case it will not receive this version of GNU grep, and there is no problem. On the other hand, if a system recei

by teddyh 4y ago

simoncion 4y ago
> This won’t, in all likelihood, “break” your scripts. Previously: > The first option is to simply replace "fgrep" with "grep -F" everywhere in all your scripts, which is correct but is more work than your other option, which is to add your own "fgrep" script somewhere in your path. script.sh: line 100: fgrep: command not found seems like evidence of a broken script to me. The fact that it can be fixed doesn't make it not broken.
- teddyh 4y ago
  We were discussing the warning printed by fgrep and egrep, not their removal. I was suggesting that you put a version of fgrep/egrep in your path which does not show the warning.
  - ajross 4y ago
    That wasn't my take. I thought we were discussing the deprecation itself. It's true that nothing is broken yet[1]. But it's clear that "broken" is where we're going, and I don't think you or the GNU maintainers have thought through the implications correctly. [1] At least, nothing that isn't sensitive to junk on stderr -- bourne scripts are not always as tolerant as you'd like.
    - teddyh 4y ago
      We were explicitly discussing GNU grep 3.8, which does not remove anything, only add warnings. And the remote possibility of breakage due to warnings is why I qualified my assertion with “in all likelihood”.