The same LineTerminator is being used for searching and printing

[ltrzesniewski]

Please tick this box to confirm you have reviewed the above.

• I have a different issue.

What version of ripgrep are you using?

ripgrep 14.1.0

features:-simd-accel,+pcre2
simd(compile):+SSE2,-SSSE3,-AVX2
simd(runtime):+SSE2,+SSSE3,+AVX2

PCRE2 10.43 is available (JIT is available)

How did you install ripgrep?

cargo install ripgrep --features pcre2

What operating system are you using ripgrep on?

Ubuntu 22.04.4 LTS on WSL

Describe your bug.

I noticed that ripgrep could insert CR characters into its output on Linux, which I didn't expect.

I took a quick look out of curiosity, and saw that the same LineTerminator is being used for searching and for printing, which I thought could be an oversight, so I figured I'd report it just in case. I don't think this has a real impact on anything though, so feel free to simply close this issue if that's ok for you.

I tracked down the culprit to this function:

ripgrep/crates/printer/src/standard.rs

Lines 1493 to 1495 in bb8601b

	fn write_line_term(&self) -> io::Result<()> {
	self.write(self.searcher.line_terminator().as_bytes())
	}

What are the steps to reproduce the behavior?

$ echo hello | rg hello --no-config --count --no-crlf | xxd
00000000: 310a                                     1.

$ echo hello | rg hello --no-config --count --crlf | xxd
00000000: 310d 0a                                  1..

What is the actual behavior?

The output changes between --crlf and --no-crlf.

Even on Linux, a CRLF end-of-line (0d 0a) is emitted when --crlf is used. I used --count to force write_line_term() to be called, but other flags such as --pretty work just as well.

What is the expected behavior?

I expected the outputs of the two commands to be the same.