在Preserve ls colouring after grep’ing中有一个类似的问题,但是如果您将着色的grep输出通过管道传输到另一个grep,那么着色就不会被保留,这让我很恼火。
例如,grep --color WORD * | grep -v AVOID
不保留第一个输出的颜色。但对我来说,ls | grep FILE
确实保留了颜色,为什么会有所不同?
发布于 2010-02-24 23:38:49
grep
有时会禁用颜色输出,例如在写入管道时。您可以使用grep --color=always
覆盖此行为
正确的命令行应该是
grep --color=always WORD * | grep -v AVOID
这非常冗长,或者您也可以只添加下面这行
alias cgrep="grep --color=always"
例如,添加到您的.bashrc
,并使用cgrep
作为带颜色的grep。在重新定义grep
时,您可能会遇到依赖于grep
的特定输出并且不喜欢ascii转义代码的脚本。
发布于 2011-10-04 04:04:24
一句忠告:
使用grep --color=always
时,传递到下一个管道的实际字符串将发生更改。这可能会导致以下情况:
$ grep --color=always -e '1' * | grep -ve '12'
11
12
13
即使选项-ve '12'
应该排除中间行,它也不会,因为在1
和2
之间有颜色字符。
发布于 2020-08-18 02:32:31
现有的答案仅解决了第一个命令为grep
时的情况(如OP所要求的,但此问题也会在其他情况下出现)。
更一般的答案
最基本的问题是,| grep
之前的命令在意识到输出要转到管道时,试图通过禁用颜色来变得“智能”。这通常是您想要的,这样ANSI转义代码就不会干扰您的下游程序。
但是,如果您希望从先前的命令发出彩色输出,则需要强制生成颜色代码,而不考虑输出接收器。强制机制是特定于程序的。
Git:使用-c color.status=always
git -c color.status=always status | grep -v .DS_Store
注意:子命令status
之前必须有-c
选项。
其他
(这是一个社区维基帖子,请随意添加您的帖子)
https://stackoverflow.com/questions/2327191
复制相似问题