6 ms·

Not having to specify "-rHInE" on every invocation is one killer reason to use ripgrep, over grep. It's a concrete advantage of you not having 100% compatibilit

by orra 6y ago

Not having to specify "-rHInE" on every invocation is one killer reason to use ripgrep, over grep. It's a concrete advantage of you not having 100% compatibility as a goal. (The other killer reason is the blitzing speed.)

ses1984 6y ago
You can solve `-rHInE` with just an alias though.
- shakow 6y ago
  Then you go back to incompatibility.
  - vbernat 6y ago
    Aliases are only active in your interactive shell.
    - orra 6y ago
      True, but then you have the occasional headscratcher that the command behaves differently in your script than when you run it manually.
    - shakow 6y ago
      Exactly, if grep behaves differently in your scripts and your shell, there's no point in not using ripgrep (or ag, or silver searcher, or whatever strikes your fancy).
      - andoriyu 6y ago
        The difference is - your script works out of the box, or you need to install ripgrep.
Sebb767 6y ago
If that is the only incompatibility, it would be easy to make a patch that checks if it is called as "grep" and default to "not -rHInE" - so one could ship ripgrep as default and yet have backwards compatibility. Some busy boxes already do that iirc. EDIT: So I've quickly looked into it and it seems nobody did an extensive comparison to the grep feature set or the POSIX specification. If I have some time later this week I might do this and check whether something like this would be viable.
- burntsushi 6y ago
  It's not even close to the only incompatibility. :-) That's a nominal one. If that were really the only thing, then sure, I would provide a way to make ripgrep work in a POSIX compatible manner. There are lots of incompatibilities. The regex engine itself is probably one of the hardest to fix. The incompatibilities range from surface level syntactic differences all the way down to how match regions themselves are determined, or even the feature sets themselves (BREs for example allow the use of backreferences). Then of course there's locale support. ripgrep takes a more "modern" approach: it ignores locale support and instead just provides what level 1 of UTS#18 specifies. (Unicode aware case insensitive matches, Unicode aware character classes, lots of Unicode properties available via \p{..}, and so on.)
  - Sebb767 6y ago
    Pity! I did look; only "-E" and "-s" diverge from the POSIX standard parameter-wise. But making significant changes to the pattern engine is probably not worth it. Thanks anyway, I enjoy rg quite a lot :)
    - nicoburns 6y ago
      It's worth noting that the implementation of ripgrep has been split up into a whole bunch of modular components. So it wouldn't be out of the question for someone to piece those together into a GNU-compatible grep implementation.
      - 6y ago

by orra 6y ago

ses1984 6y ago

You can solve `-rHInE` with just an alias though.

shakow 6y ago
Then you go back to incompatibility.
- vbernat 6y ago
  Aliases are only active in your interactive shell.
  - orra 6y ago
    True, but then you have the occasional headscratcher that the command behaves differently in your script than when you run it manually.
  - shakow 6y ago
    Exactly, if grep behaves differently in your scripts and your shell, there's no point in not using ripgrep (or ag, or silver searcher, or whatever strikes your fancy).
    - andoriyu 6y ago
      The difference is - your script works out of the box, or you need to install ripgrep.

Sebb767 6y ago

If that is the only incompatibility, it would be easy to make a patch that checks if it is called as "grep" and default to "not -rHInE" - so one could ship ripgrep as default and yet have backwards compatibility. Some busy boxes already do that iirc. EDIT: So I've quickly looked into it and it seems nobody did an extensive comparison to the grep feature set or the POSIX specification. If I have some time later this week I might do this and check whether something like this would be viable.

burntsushi 6y ago
It's not even close to the only incompatibility. :-) That's a nominal one. If that were really the only thing, then sure, I would provide a way to make ripgrep work in a POSIX compatible manner. There are lots of incompatibilities. The regex engine itself is probably one of the hardest to fix. The incompatibilities range from surface level syntactic differences all the way down to how match regions themselves are determined, or even the feature sets themselves (BREs for example allow the use of backreferences). Then of course there's locale support. ripgrep takes a more "modern" approach: it ignores locale support and instead just provides what level 1 of UTS#18 specifies. (Unicode aware case insensitive matches, Unicode aware character classes, lots of Unicode properties available via \p{..}, and so on.)
- Sebb767 6y ago
  Pity! I did look; only "-E" and "-s" diverge from the POSIX standard parameter-wise. But making significant changes to the pattern engine is probably not worth it. Thanks anyway, I enjoy rg quite a lot :)
  - nicoburns 6y ago
    It's worth noting that the implementation of ripgrep has been split up into a whole bunch of modular components. So it wouldn't be out of the question for someone to piece those together into a GNU-compatible grep implementation.
    - 6y ago