4 ms·

It’s a great tool, but it’s not a posix compliant grep.

shmerl 2y ago
I think it's more about having a stable interface. If it's not stable - you can't use it as a base tool long term. But if it's stable, what difference does it make if it's POSIX compliant or not?
- grandempire 2y ago
  Because you aren’t the first one here. Countless lines of software exist which assumes posix. People learned how to use computers and know the grep commands. There is documentation for posix in places where it needs to be. It handles important edge cases which were needed by some groups and that was formalized into a standards requirement. So changing to the new thing invalidates all that existing value. That’s not argument to never do anything new, but it’s an argument why for your UNIX-like OS should ship the standard boring thing instead of the shiny new thing in the base install.
  - estebank 2y ago
    Having ripgrep installed by default doesn't preclude grep also being installed.
    - grandempire 2y ago
      Indeed. So why it should it come by default?
      - bbkane 2y ago
        Have you used ripgrep? It's so much nicer for day to day usage! That's why it should come by default. Seriously, try it out, I'm sure you'll love it!
  - shmerl 2y ago
    I'd say POSIX is sometimes overrated. Example: https://github.com/mpv-player/mpv/commit/1e70e82baa91 https://github.com/mpv-player/mpv/commit/1e70e82baa91 Anyway, I don't see any of that as a reason for not having ripgrep installed everywhere by default and as an argument for not using it.
    - grandempire 2y ago
      It doesn’t matter if it’s over or underrated - what matters is if you want to be compatible with existing code and documentation. I wish C didn’t have strtok, but it’s too late.
      - shmerl 2y ago
        I don't specifically want to be compatible with it, no. I mean if ripgrep works for my needs - I'll use it and won't worry if it's POSIX compatible or not.
        grandempire 2y ago
        Great. But we don’t need it in base.
        shmerl 2y ago
        That's what I don't necessarily agree with.
burntsushi 2y ago
So? There are (likely) tons of tools that come installed by default in your distro that aren't POSIX compliant. Or aren't even mentioned by POSIX at all. For example, on Archlinux, `base` (the minimal set of packages to install) includes `systemd`. `systemd` isn't POSIX. Now, you could say having both grep and ripgrep installed by default would be somewhat wasteful. As the author of ripgrep, I agree with that. ripgrep is fine being something you opt into so long as coreutils is already included by default. I'm just tired of people hiding behind POSIX compliance. One wonders how many of your invocations of grep are not POSIX compliant. (A strict POSIX grep is laughably minimal. To the point that not even minimal implementations of coreutils, like busybox, don't stick to the strict set prescribed by POSIX.) I'm not even aware of any grep implementation that doesn't implement something beyond what POSIX requires. Of course, grep still has a POSIX compliant base. And so long as your scripts only rely on that POSIX compliant base (no -a or -r or -o flags, for example), you can reap the portability benefits of POSIX.
- grandempire 2y ago
  > I'm just tired of people hiding behind POSIX compliance. grep exists in base primarily to support shell scripting, as well as the benefits of standardization that I mentioned. That’s not hiding - it’s a basic expectation if you want scripts to run. Why should ripgrep be on base and what kind of overhead are we adding to install? > how many of your invocations of grep are not POSIX compliant. It would be a different argument if ripgrep was compliant with extensions, like gnugrep, but being a completely separate tool with a similar name, it doesn’t fill the same role. I like it and install it when I need it.
  - burntsushi 2y ago
    I think my comment already addressed every single piece of what you said here. And you're shifting your original claim! You are no longer hiding behind POSIX compliance here. Instead, you're making a more nuanced argument based on more than just POSIX compliance, and one that I find very reasonable! But that's not what you originally said.
    - 2y ago

I think it's more about having a stable interface. If it's not stable - you can't use it as a base tool long term. But if it's stable, what difference does it make if it's POSIX compliant or not?

grandempire 2y ago
Because you aren’t the first one here. Countless lines of software exist which assumes posix. People learned how to use computers and know the grep commands. There is documentation for posix in places where it needs to be. It handles important edge cases which were needed by some groups and that was formalized into a standards requirement. So changing to the new thing invalidates all that existing value. That’s not argument to never do anything new, but it’s an argument why for your UNIX-like OS should ship the standard boring thing instead of the shiny new thing in the base install.
- estebank 2y ago
  Having ripgrep installed by default doesn't preclude grep also being installed.
  - grandempire 2y ago
    Indeed. So why it should it come by default?
    - bbkane 2y ago
      Have you used ripgrep? It's so much nicer for day to day usage! That's why it should come by default. Seriously, try it out, I'm sure you'll love it!
- shmerl 2y ago
  I'd say POSIX is sometimes overrated. Example: https://github.com/mpv-player/mpv/commit/1e70e82baa91 https://github.com/mpv-player/mpv/commit/1e70e82baa91 Anyway, I don't see any of that as a reason for not having ripgrep installed everywhere by default and as an argument for not using it.
  - grandempire 2y ago
    It doesn’t matter if it’s over or underrated - what matters is if you want to be compatible with existing code and documentation. I wish C didn’t have strtok, but it’s too late.
    - shmerl 2y ago
      I don't specifically want to be compatible with it, no. I mean if ripgrep works for my needs - I'll use it and won't worry if it's POSIX compatible or not.
      - grandempire 2y ago
        Great. But we don’t need it in base.
        shmerl 2y ago
        That's what I don't necessarily agree with.

burntsushi 2y ago

So? There are (likely) tons of tools that come installed by default in your distro that aren't POSIX compliant. Or aren't even mentioned by POSIX at all. For example, on Archlinux, `base` (the minimal set of packages to install) includes `systemd`. `systemd` isn't POSIX. Now, you could say having both grep and ripgrep installed by default would be somewhat wasteful. As the author of ripgrep, I agree with that. ripgrep is fine being something you opt into so long as coreutils is already included by default. I'm just tired of people hiding behind POSIX compliance. One wonders how many of your invocations of grep are not POSIX compliant. (A strict POSIX grep is laughably minimal. To the point that not even minimal implementations of coreutils, like busybox, don't stick to the strict set prescribed by POSIX.) I'm not even aware of any grep implementation that doesn't implement something beyond what POSIX requires. Of course, grep still has a POSIX compliant base. And so long as your scripts only rely on that POSIX compliant base (no -a or -r or -o flags, for example), you can reap the portability benefits of POSIX.

grandempire 2y ago
> I'm just tired of people hiding behind POSIX compliance. grep exists in base primarily to support shell scripting, as well as the benefits of standardization that I mentioned. That’s not hiding - it’s a basic expectation if you want scripts to run. Why should ripgrep be on base and what kind of overhead are we adding to install? > how many of your invocations of grep are not POSIX compliant. It would be a different argument if ripgrep was compliant with extensions, like gnugrep, but being a completely separate tool with a similar name, it doesn’t fill the same role. I like it and install it when I need it.
- burntsushi 2y ago
  I think my comment already addressed every single piece of what you said here. And you're shifting your original claim! You are no longer hiding behind POSIX compliance here. Instead, you're making a more nuanced argument based on more than just POSIX compliance, and one that I find very reasonable! But that's not what you originally said.
  - 2y ago