5 ms·

What's strange to me is that some of these new incarnations use different syntax and/or flags. If those were the same you get the advantage of migraters not hav

by jorvi 9y ago

What's strange to me is that some of these new incarnations use different syntax and/or flags. If those were the same you get the advantage of migraters not having to relearn anything. It also allows for the beauty of aliasing the new tool to the old name!

coldtea 9y ago
>If those were the same you get the advantage of migraters not having to relearn anything. You'd also loose the ability to improve upon arcane/ad-hoc and obsolete flags and syntax choices though too. And for the "same flags" to make any sense, you'd also be constrained to produce the same output and even recreate the same quirks. At which point, might as well just use the originals.
- bm1362 9y ago
  I agree with you, the reason these new tools are useful is they’re much more intuitive than the esoteric flags that have built up over the last 30 years.
burntsushi 9y ago
There is a very simple response to this: if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. The whole point is that it is very similar but does some things differently that a lot of people consider "better." I imagine this is truish for the other tools mentioned in this thread as well. (And still other tools, like xsv, have no pre-existing standard. Standard UNIX tooling doesn't work on CSV.)
- yorwba 9y ago
  Have you considered making a "grep mode" for ripgrep? If it's triggered by the name of the binary, it could provide both the traditional flags as well as its own.
  - burntsushi 9y ago
    A couple of people have asked for it, but the ROI isn't worth it. Think about all the various POSIX compatibilities, locale support, subtle differences in flag meanings, supporting the different flavors of regex (BREs, EREs) and of course, all the various differences in the regex engine itself, such as leftmost-first vs leftmost-longest matching, and subcapture match locations as well. I feel like people significantly underestimate the difficulty of being 100% compatible with another tool. Not even GNU grep is strictly POSIX compatible, for example. To get POSIX compatibility, you need to set the POSIXLY_CORRECT environment variable. And then what do I gain from this? Do you think distros are going to start throwing away GNU grep for ripgrep? No, I don't think so. So what then? A few people will have the pleasure of using ripgrep with grep's flags, even though they are already significantly similar? Not. Worth. It. Now... If someone does think it's worth it, then they are more than welcome to start that journey. Most of ripgrep is factored out into libraries, so in theory there is a lot of reuse possible. But if you want to support compatibility all the way down into the regex engine, then you might be hosed.
    - SOLAR_FIELDS 9y ago
      Is POSIXLY_CORRECT supposed to be a play on “politically correct”? If so that’s pretty amusing.
      - thristian 9y ago
        RMS' original convention for requesting GNU tools be compatible with questionable legacy behaviour was POSIX_ME_HARDER, but he toned it down as a gesture of goodwill to the other members of the POSIX committee.
        SOLAR_FIELDS 9y ago
        That’s so great and puts the variable name into even better context
  - nitrogen 9y ago
    You could write yourself a wrapper that translates supported flags for you, then falls back to grep for anything weird.
- geezerjay 9y ago
  > if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. That seems to miss a huge lesson: backward compatibility eases transition, new features retain users. Therefore, your assertion makes only sense if there would be no point in attracting existing users to use a tool whose added value is entirely irrelevant.
  - burntsushi 9y ago
    It doesn't miss any lesson. It's a trade off. The headline feature involves a default mode of operation that's fundamentally incompatible with GNU grep. Full stop. ripgrep is an evolution on ag, which in turn is an evolution on ack. All three tools have similar defaults, so in fact, ripgrep preserves some amount of backward compatibility with previously established tools in terms of the default mode of operation. Just not GNU grep. This goes further in that the intersection between ripgrep's features/flags and GNU grep's features is quite large---certainly much larger than the differences between them, which is just another form of preserving backward compatibility. This was done on purpose for exactly the lesson you're claiming I missed: backward compatibility eases transition. (The context of this conversation was a 100% backward compatible version of ripgrep with GNU grep. See my other comments on ROI. Just because I can argue against 100% backward compatibility doesn't mean I've missed the importance of backward compatibility.)

by jorvi 9y ago

coldtea 9y ago

>If those were the same you get the advantage of migraters not having to relearn anything. You'd also loose the ability to improve upon arcane/ad-hoc and obsolete flags and syntax choices though too. And for the "same flags" to make any sense, you'd also be constrained to produce the same output and even recreate the same quirks. At which point, might as well just use the originals.

bm1362 9y ago
I agree with you, the reason these new tools are useful is they’re much more intuitive than the esoteric flags that have built up over the last 30 years.

burntsushi 9y ago

There is a very simple response to this: if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. The whole point is that it is very similar but does some things differently that a lot of people consider "better." I imagine this is truish for the other tools mentioned in this thread as well. (And still other tools, like xsv, have no pre-existing standard. Standard UNIX tooling doesn't work on CSV.)

yorwba 9y ago
Have you considered making a "grep mode" for ripgrep? If it's triggered by the name of the binary, it could provide both the traditional flags as well as its own.
- burntsushi 9y ago
  A couple of people have asked for it, but the ROI isn't worth it. Think about all the various POSIX compatibilities, locale support, subtle differences in flag meanings, supporting the different flavors of regex (BREs, EREs) and of course, all the various differences in the regex engine itself, such as leftmost-first vs leftmost-longest matching, and subcapture match locations as well. I feel like people significantly underestimate the difficulty of being 100% compatible with another tool. Not even GNU grep is strictly POSIX compatible, for example. To get POSIX compatibility, you need to set the POSIXLY_CORRECT environment variable. And then what do I gain from this? Do you think distros are going to start throwing away GNU grep for ripgrep? No, I don't think so. So what then? A few people will have the pleasure of using ripgrep with grep's flags, even though they are already significantly similar? Not. Worth. It. Now... If someone does think it's worth it, then they are more than welcome to start that journey. Most of ripgrep is factored out into libraries, so in theory there is a lot of reuse possible. But if you want to support compatibility all the way down into the regex engine, then you might be hosed.
  - SOLAR_FIELDS 9y ago
    Is POSIXLY_CORRECT supposed to be a play on “politically correct”? If so that’s pretty amusing.
    - thristian 9y ago
      RMS' original convention for requesting GNU tools be compatible with questionable legacy behaviour was POSIX_ME_HARDER, but he toned it down as a gesture of goodwill to the other members of the POSIX committee.
      - SOLAR_FIELDS 9y ago
        That’s so great and puts the variable name into even better context
- nitrogen 9y ago
  You could write yourself a wrapper that translates supported flags for you, then falls back to grep for anything weird.
geezerjay 9y ago
> if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. That seems to miss a huge lesson: backward compatibility eases transition, new features retain users. Therefore, your assertion makes only sense if there would be no point in attracting existing users to use a tool whose added value is entirely irrelevant.
- burntsushi 9y ago
  It doesn't miss any lesson. It's a trade off. The headline feature involves a default mode of operation that's fundamentally incompatible with GNU grep. Full stop. ripgrep is an evolution on ag, which in turn is an evolution on ack. All three tools have similar defaults, so in fact, ripgrep preserves some amount of backward compatibility with previously established tools in terms of the default mode of operation. Just not GNU grep. This goes further in that the intersection between ripgrep's features/flags and GNU grep's features is quite large---certainly much larger than the differences between them, which is just another form of preserving backward compatibility. This was done on purpose for exactly the lesson you're claiming I missed: backward compatibility eases transition. (The context of this conversation was a 100% backward compatible version of ripgrep with GNU grep. See my other comments on ROI. Just because I can argue against 100% backward compatibility doesn't mean I've missed the importance of backward compatibility.)