我在Ubuntu上输入cat .bash_history | grep git，它返回了


二进制文件（标准输入）匹配项


我的bash_history确实存在并且有它的许多行都以git开头。

是什么原因导致显示此错误，我该如何解决？

评论

文件.bash_history（文件〜/ .bash_history）的输出是什么？
输出为.bash_history：数据
由于某种原因，这只是发生在我的Apache日志中。感谢您的问答
密切相关：unix.stackexchange.com/q/19907/5510

#1 楼

假定文件.bash_history以非文本数据开头，因此grep将文件视为二进制文件。 file .bash_history输出确认了这一点：

.bash_history: data


您可以从头开始读取几个字节，以得到一致的视图：

head -c1K .bash_history


我在这里先阅读1 KiB。

您可以将STDOUT输送到hexdump / od或类似产品。


作为旁注，grep使用文件名作为参数，因此cat在这里没有用；试试这个：

grep git .bash_history


评论

我仍然不确定如何解决grep问题，head -c1k .bash_history读取了我的.bash_history文件的前38行。一切都可读

–answeranswerker
17年1月8日在5:22


@Tata​​kaiWasumi grep -a git .bash_history的输出是什么？

–heemayl
17年1月8日在5:29
可行！我从中得到了想要的一切。 -a做什么？

–answeranswerker
17年1月8日在5:31
@Tata​​kaiWasumi -a使grep将文件视为二进制文件。

–heemayl
17年1月8日在5:34
-a使grep像对待文本一样处理二进制文件。

– lashgar
18年4月6日在23:01

#2 楼

您可以使用grep -a 'pattern'。从man grep页面开始：

-a，--text
处理二进制文件，就好像它是文本一样；这等效于--binary-files = text选项。


评论

当使用-z标志跨几行进行匹配时，这对我有帮助。

– Stragu
18-4-24在7:51


它对我有用，但仍然很奇怪，因为我的文件不是二进制文件。 [grid @ serverdg2跟踪] $文件listener.log listener.log：数据

– DBA Jr
20年12月1日，下午3:42

#3 楼

当我想grep我的.bash_history时，我遇到了同样的问题。 （小注：我重命名了历史记录，因此创建了一个新的历史记录。这个新历史记录未被视为二进制文件。）这不是完全正确。
从grep的手册页：

如果未指定文件，或者给出文件“-”，则grep搜索标准输入。

因此您可以使用cat并将其通过管道传输到grep。但是，这不能解决cat被视为二进制文件的问题。唯一正确的方法是使用grep（就像@AK_的答案一样），无论是直接使用.bash_history历史记录还是使用grep -a和管道都使用历史记录。

cat .bash_history | grep -a git

或
grep -a git .bash_history


#4 楼

错误是由于文件中的数据为二进制数据，您可以使用字符串命令查看通常可使用strings
grep
搜索的可读部分（即strings data | grep -i whatever）。

评论

这没有解决问题的第一部分，即“问题的原因”。

– Kusalananda♦
20 Mar 24 '20 at 9:47

#5 楼

这可能是bash历史记录中的空字节引起的。删除具有空字符的行可以解决此问题。您可以使用grep的Perl-regexp模式进行检查：
grep -Pa '\x00' .bash_history

这篇文章对非unix系统提出了建议。