Come faccio a rispettare la grep rispetto ai colori ANSI quando si estrae l'output in pipe? Sono felice di usare qualcos'altro (perl?) Invece di grep.grep attraverso testo colorato, ad es. gcc | colorgcc | grep regexp
mio usercase: Voglio
gcc foobar.c | colorgcc | grep regexp
ls --color | grep filename
lavoro bene con i colori (su un terminale UNIX utilizzando ANSI sfugge).
Gli esempi di test di comportamento che voglio:
echo -e "he\e[35mllo\e[00m" world |grep hell ==> he\e[35mllo\e[00m world
echo -e "\e[35m removed line\nhello\e[00m" world |grep hell ==> \e[35mhello\e[00m world
echo -e "\e[35m rem\e[1moved line\nhello\e[00m" world | grep hell ==> \e35m\e1mhello\e[00m world
Attualmente la prima linea dà la stringa vuota, e la seconda dà stringa 'ciao \ e [mondo 00m' uncolorised. Qui \ e [35m e \ e00m sono modificatori di colore (attributo): il colore di una lettera è determinato dalle ultime sequenze di escape di colore (attributo) di forma \ e [P1; P2; .. m dove P1, P2, ecc sono sequenza di cifre; \ e [P1m \ e [P2m è equivalente a \ e [P1; P2m. \ e [0m rende il colore predefinito e dimentica tutte le precedenti sequenze \ e [.. m: \ e [34m \ e [0m equivale a \ e [0m. Ci sono diversi attributi indipendenti (audacia, colore dello sfondo, colore di primo piano/lettera); ogni numero in una sequenza di escape interessa solo uno di essi. Quindi \ e [1m \ e [35m equivale a \ e [1; 35m ma non \ e [35; 1m né \ e [35m; tuttavia, \ e [34m \ e [35m sono equivalenti a \ e [35m perché entrambi influenzano lo stesso effetto (vale a dire, il colore della lettera/foregrnound).
primo tentativo di una soluzione: 'foobar.c gcc | colorgcc | meno -R +/regexp'. 'less -R' capisce i codici colore e cercherà intorno a loro. – nneonneo