Unexpected ^O when using fzf --ansi

[netei]

printf "$(tput setaf 2)foo$(tput sgr0)bar\nbar\n"

echoes

foobar
bar

while printf "$(tput setaf 2)foo$(tput sgr0)bar\nbar\n" | fzf --ansi

echoes

foo^Obar
bar

I've replaced what is placed in green by bold because that's the only way to format on github.

I have the latest fzf version, 0.10.8

[netei]

It works fine if using $(tput setaf 7) (for white)

[junegunn]

Thanks, I'll fix it.

[junegunn]

Hmm, it turned out that it's an issue of how ncurses prints non-printable characters.

echo $'\x0f' | fzf

echo $'\x01' | fzf
# ...

#include <stdio.h>
#include <unistd.h>
#include <curses.h>

int main() {
  WINDOW * win = initscr();
  char msg[100];
  sprintf(msg, "Hello,%cworld!", (char) 0xf);
  mvaddstr(0, 0, msg);
  refresh();
  sleep(2);
  delwin(win);
  endwin();
  refresh();
}

[junegunn]

I'm not 100% sure if it's the correct approach, but simply ignoring non-printable characters fixes the issue.

[netei]

Great, Thanks !

[nevesnunes]

This issue still happens if the command passed to the --preview option uses tput sgr0 somewhere in it's output.

I investigated what was being printed and found this snippet in the manual page of terminfo:

tparm parameter      attribute        escape sequence                

none                 none             \E[0m                          
p1                   standout         \E[0;1;7m                      
p2                   underline        \E[0;4m                        
p3                   reverse          \E[0;7m                        
p4                   blink            \E[0;5m                        
p5                   dim              not available                  
p6                   bold             \E[0;1m                        
p7                   invis            \E[0;8m                        
p8                   protect          not used                       
p9                   altcharset       ^O (off) ^N (on)               

Since sgr0 turns off these attributes, it will output ^O for the last parameter, which is encoded in it's octal form, unlike the other espace sequences. Indeed, it can be removed from a string like this:

tr -d '\017' <<< "$string"

I have no idea why this particular escape sequence isn't handled properly, but maybe these findings can help you with dealing with this problem.

[junegunn]

@nevesnunes Thanks for the info. The ANSI procesor of fzf only handles sequences that start with \E, so ^O and ^N are left untouched. I'll remove them from preview output.