ripgrep echos unescaped input to terminal, for filenames and regexes

[andychu]

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

• I have a different issue.

What version of ripgrep are you using?

13.0.0

How did you install ripgrep?

apt-get

What operating system are you using ripgrep on?

Debian

Describe your bug.

ripgrep echos unescaped input to terminal, for filenames and regexes

What are the steps to reproduce the behavior?

red=$'\x1b[31m RED \x1b[0;0m'

rg pat "$red" # filename

rg "$red' # pattern

What is the actual behavior?

I see red text

What is the expected behavior?

It should probably be escaped, at least in the filename case

I noticed this when testing a bunch of programs, as mentioned here

https://lobste.rs/s/qwcov5/deja_vu_ghostly_cves_my_terminal_title#c_js5pfq

There are two categories of programs:

• bash, perl, python2, lua, node JS, grep, ripgrep

vs.

• ls and cat (coreutils), python3, ruby, OSH/YSH

This is possibly debatable, but I think the latter behavior is better

[BurntSushi]

I imagine it will do the same for file data too (which has been reported before), which ripgrep just dumps to stdout as is. I'm not really sure this is worth fixing.

[andychu]

Yeah I am not saying it's a security issue -- all this stuff with terminals is kinda ambiguous

Just saying that programs do disagree on this, but the trend is toward the latter behavior. At least with coreutils in 2016 - https://www.gnu.org/software/coreutils/quotes.html

I think it's more usable to see the quoted representation of what you typed, rather than having invisible chars, or red chars

i.e. if there is a garbage filename on the file system, it could be more noticeable to the user in quoted form

(I never thought about the actual file contents on stdout, though come to think of it having a mode to show that is something I might use, although it could also be a filter after grep/rg)