Open misaki-web opened 1 year ago
I can confirm that this exists on master.
This may be difficult to fix. I believe there have been past issues similar to this.
It's also worth pointing out this is not really specific to --passthru
(and I've changed the issue title accordingly). Rather, it's what ripgrep does even without --passthru
because the alternative is generally not great:
$ printf "A" | xxd
00000000: 41 A
$ printf "A" | rg . | xxd
00000000: 410a A.
$ printf "A" | grep . | xxd
00000000: 410a A.
Notice that grep behaves the same here, so the appeal to the behavior of other tools in this space can go either way.
This might wind up being a wontfix
bug, and I'm pretty sure the existing behavior is actually intentional. With that said, I believe the way ripgrep deals with line terminators is generally sub-optimal, and I can agree that preserving them as they are in the input file can be useful. The gnarly part of this issue though is even if we could fix it, it's not clear that making --passthru
better on this metric would be worth making ripgrep worse in the general case. That is, when searching arbitrary files and printing a match on the last line, you really really want to emit a line terminator even if the original doesn't end with one.
Either way, this is unlikely to be fixed any time soon.
Using ripgrep 13.0.0 on Ubuntu 22.10, the argument
--passthru
adds a new line at the end of data (so it can't be used to get only changes explicitly requested with the-r
argument). It seems to be a bug, the documentation doesn't refer to adding a newline, but onlyPrint both matching and non-matching lines
, implying that data should be the same at the end of the process (unless replacements occur).Example of the issue:
Expected result: no newline added at the end, like
sed
or other similar tools:Here's an example with
diff
:The same process with
sed
results in a different output fordiff
: