3 ms·

> See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks. The 'fgrep' and 'egrep' didn't thro

> See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks. The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected. Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.

ajross 1y ago
> didn't throw errors, it would just send a warning to standard error Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams. > Those commands were never standardized "Those commands" were present in v7 unix in 1979!
- larusso 1y ago
  I think he means POSIX. Didn’t check but in some cases posix only covers some options a tool provides not all. It’s a hard lesson I learned while keeping shell scripts portable between Linux and macOS.
  - collinfunk 1y ago
    Yep. I was slightly incorrect in my original message, though. SUSv2 (1997) specified egrep and fgrep but marked them LEGACY. POSIX.1-2001 removed them. The only place that that doesn't support 'grep -E' and 'grep -F' nowadays is Solaris 10. But if you are still using that you will certainly run into many other missing options. [1] https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.html https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.ht... [2] https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.html https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.ht...
    - ajross 1y ago
      "GNU grep implemented a change that breaks pre-existing scripts using a 46 year old API, but it's OK because the required workaround works everywhere but Solaris 10" seems like not a great statement of engineering design to me.
      - 1718627440 1y ago
        "GNU grep added a warning to inform you of the deprecation which happened 28 years ago, but only to stderr, and still works like you expect", does to me.
        ajross 1y ago
        Meh. Look, it broke code. "Still works like you expect" is 100% false. The deprecation argument is at least... arguable. It was indeed retired from POSIX. But needless deprecation is itself a smell in a situation where you can't audit all the code that uses it. Don't do that. It breaks stuff. It broke the updates in the linked article too. If you have an API, leave it there absent extremely strong arguments for its removal.

ajross 1y ago

> didn't throw errors, it would just send a warning to standard error Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams. > Those commands were never standardized "Those commands" were present in v7 unix in 1979!

larusso 1y ago
I think he means POSIX. Didn’t check but in some cases posix only covers some options a tool provides not all. It’s a hard lesson I learned while keeping shell scripts portable between Linux and macOS.
- collinfunk 1y ago
  Yep. I was slightly incorrect in my original message, though. SUSv2 (1997) specified egrep and fgrep but marked them LEGACY. POSIX.1-2001 removed them. The only place that that doesn't support 'grep -E' and 'grep -F' nowadays is Solaris 10. But if you are still using that you will certainly run into many other missing options. [1] https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.html https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.ht... [2] https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.html https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.ht...
  - ajross 1y ago
    "GNU grep implemented a change that breaks pre-existing scripts using a 46 year old API, but it's OK because the required workaround works everywhere but Solaris 10" seems like not a great statement of engineering design to me.
    - 1718627440 1y ago
      "GNU grep added a warning to inform you of the deprecation which happened 28 years ago, but only to stderr, and still works like you expect", does to me.
      - ajross 1y ago
        Meh. Look, it broke code. "Still works like you expect" is 100% false. The deprecation argument is at least... arguable. It was indeed retired from POSIX. But needless deprecation is itself a smell in a situation where you can't audit all the code that uses it. Don't do that. It breaks stuff. It broke the updates in the linked article too. If you have an API, leave it there absent extremely strong arguments for its removal.