There is a simlar question in Preserve ls colouring after grep’ing but it annoys me that if you pipe colored grep output into another grep that the coloring is not preserved.
As an example grep --color WORD * | grep -v AVOID does not keep the color of the first output. But for me ls | grep FILE do keep the color, why the difference ?
grep sometimes disables the color output, for example when writing to a pipe. You can override this behavior with grep --color=always
The correct command line would be
grep --color=always WORD * | grep -v AVOID This is pretty verbose, alternatively you can just add the line
alias cgrep="grep --color=always" to your .bashrc for example and use cgrep as the colored grep. When redefining grep you might run into trouble with scripts which rely on specific output of grep and don't like ascii escape code.
grep. alias grep='grep --color=auto so I need to just alter my ~/.bashrc where it was defined in the first place.
A word of advice:
When using grep --color=always, the actual strings being passed on to the next pipe will be changed. This can lead to the following situation:
$ grep --color=always -e '1' * | grep -ve '12' 11 12 13 Even though the option -ve '12' should exclude the middle line, it will not because there are color characters between 1 and 2.
--color=auto, then it should pick up the fact you're piping it somewhere else and suppress colors altogether, but it kind of defeats the purpose. If you still want colored results, I guess you could grep it again at the last pipe using --color.
--color=always does work, with, I assume, the caveats stated above.
\e[38;5;155m 12 14 16 18 \e[m should match 15. I'm not good enough with Grep to tell you if it's possible to match "15 but not between \e[ or help with the "12" split by formatting.\e[...m?). You can find the start and end of a match in a raw line, then find the corresponding point of each in the formatted line. E.g. 11 12 13 has "12" from 3-5 which is 3-17 in 11 1\e[38;5;155m2\e[39m 13, or 3-20 depending. Then bold it yourself: 11 \e[1m1\e[38;5;155m2\e[39m\e[2m 13 (which moves the correspondence to 9-23.)The existing answers only address the case when the FIRST command is grep (as asked by the OP, but this problem arises in other situations too).
The basic problem is that the command BEFORE | grep, tries to be "smart" by disabling color when it realizes the output is going to a pipe. This is usually what you want so that ANSI escape codes don't interfere with your downstream program.
But if you want colorized output emanating from earlier commands, you need to force color codes to be produced regardless of the output sink. The forcing mechanism is program-specific.
git -c color.status=always status | grep -v .DS_Store Note: the -c option must come BEFORE the subcommand status.
(this is a community wiki post so feel free to add yours)
--color=always option, as in: git branch --color=always | grep --color=never -v fooSimply repeat the same grep command at the end of your pipe.
grep WORD * | grep -v AVOID | grep -v AVOID2 | grep WORD
grep -v AVOID * | grep WORD
--color=always to the last command for this to work for me. (The first command producing color was git grep.) And I'll add that grep -v'ing my entire codebase would seem rather excessive...grep -P is okay for you. I believe your command would be something like grep -P '(?=^((?!AVOID).|^(?!AVOID2).)*$)WORD'. According to the user, it'll "quit" (move on) early if it meets an excluded pattern. I couldn't get it to match WORD more than once though. I'm not a Perl guy and I'm bad with Grep to begin with.
grep fobar $(find . -name \*.json)instead offind . -name \*.json | xargs grep fobarfor example.