^O characters in coloured output about ripgrep HOT 9 CLOSED

Yup, I can reproduce it. Setting TERM=screen.linux was key.

from ripgrep.

N.B. When I'm in a screen session, if I do TERM=xterm rg -p foo | less -R then things appear to work. When TERM=screen, I see the same ^0 characters as the OP. I wonder if it's a bug in the term library I'm using.

from ripgrep.

Same here (ArchLinux, tmux 2.2, rg 0.2.1). In tmux my $TERM is screen-256color, but running TERM=xterm rg temp | less helps.

from ripgrep.

Yes, I can work around it. ^O is shift-in, i.e. switch to non-graphic character set, so may be part of a generic "reset" sequence. As I need to add --color always to use with less, I need to put a wrapper script around it anyway so I'll add TERM=whatever there. Perhaps it only needs documenting. However if there was a way to just reset colours without also resetting character set that might avoid confusion.

from ripgrep.

@uazu Ah thanks for the explanation. I think other tools seem to work fine, so we should try to fix it. Documenting it as a known bug in the README is also a good idea. By the way, you may also be interested in the -p/--pretty flag. :-)

from ripgrep.

According to less(1), the -R option tells less to assume all sequences of the form ESC [ ... m are zero-width, and pass them through verbatim. ^O is not of that form, so less makes it printable. But where does the ^O come from?

Looking at the terminfo database entry for screen, we see:

$ infocmp -1 screen | grep sgr0
    sgr0=\E[m\017,

...so whenever ripgrep calls .reset(), the term crate looks up the sequence associated with sgr0 ("set graphical rendition to 0" i.e. all fancy things turned off), the terminfo database for screen defines sgr0 to be "ESC [ m ^O" and so that's what gets written to the screen.

If there's a bug here, I'd say it's in less for half-assing its escape-sequence passthrough.

from ripgrep.

Well, I now have a wrapper around ripgrep which sets TERM=xterm and pipes to less and everything is fine (and I use ripgrep all the time now -- Thanks!). However, maybe using the 'reset' (sgr0) sequence in this application is overkill, since you don't need to reset everything, but rather just the colours. If there is some other terminfo string that can be used for that then the problem is avoided. Otherwise the TERM=xterm workaround needs to be documented, since I'm sure some other people will want to use ripgrep with less on screen.

from ripgrep.

sgr0 is definitely the canonical way to do it. And it's not just colours - ripgrep also makes some text bold.

from ripgrep.

Thanks. I confirm the fix.

from ripgrep.